On Thu, Jul 02, 2009 at 01:22:16PM -0700, Jeffrey Thalhammer wrote:
>    On Jul 2, 2009, at 2:28 AM, Tim Bunce wrote:
> 
>      So you could say that it ultimately boils down to caching (as it usually
>      does) but with the twist that architectural-level changes are needed in
>      order to enable the kinds of caching you need?
> 
>    I think it is a little more than that.  Rather than caching
>    subroutine calls, we should be transforming the data into something
>    that is better suited to the types of things that Perl-Critic does.
>    We don't just need faster subs, we need smarter data.  Does that
>    make any sense?  Maybe the difference is too abstract to really
>    matter?

No, I can see what you're saying and I understand. Thanks.

>        There's one line in the middle there that consumes way more total time 
> than
>        all the rest.  It is marked in red, but it gets lost among all the
>        surrounding red/orange/yellow squares.
> 
>      Umm, it is the only line with a red square in the first column, which
>      certainly draws atention to it.
> 
>    Yes, that's true.  I'm just distracted by the colors in other columns.

I'm going to desaturate the colors for the next release.

>    So far, I haven't had an occasion to think about the
>    average time (perhaps that might be better presented as a tool tip).

Yes, it's not much use. (Though slightly more useful than the Average
statement execution time _per file_ shown on the index page. I keep
meaning to drop that column.)

>    And I tend to forget what each column means.  It would be
>    great if the column headers floated so they were always visible
>    (yummy eye candy).

Patches welcome!

>      The colouring of the squares is driven by the statement profiler.
>      You're saying you want greater visibility of the results from the
>      subroutine profiler. I've thought about that before but didn't
>      see a good way to add it into the pseudo-comment annotations without
>      them becoming too visually distracting.
> 
>    I think part of my difficulty stems from dealing with inclusive vs.
>    exclusive time.  Conceptually, I understand the difference between
>    the two.  But practically, I'm not sure how to interpret each of
>    them and make decisions.  I don't know how to do this, but perhaps
>    your OSCON presentation could include a couple scenarios that
>    demonstrate how to use the two numbers appropriately.

Noted. (I tend to think of them as "time spent in here" and "time spent below".)

>    The question that I'm always asking is "Which sub/block/line is
>    taking the most time?"  So I would welcome any information that
>    makes the answer more obvious.  But I acknowledge that I might be
>    asking the wrong question in the first place.  Thanks for having
>    this conversation with me!  I think it will help me understand
>    NYTProf much better, once this all sinks in.

Me too! :)

Try out the current trunk and let me know what you think of the extra
columns and the two treemaps.

Tim.

--~--~---------~--~----~------------~-------~--~----~
You've received this message because you are subscribed to
the Devel::NYTProf Development User group.

Group hosted at:  http://groups.google.com/group/develnytprof-dev
Project hosted at:  http://perl-devel-nytprof.googlecode.com
CPAN distribution:  http://search.cpan.org/dist/Devel-NYTProf

To post, email:  [email protected]
To unsubscribe, email:  [email protected]
-~----------~----~----~----~------~----~------~--~---

Reply via email to