On Tue, Apr 13, 2010 at 11:31:35PM +0100, Tim Bunce wrote:
> NYTProf reporting has always handled string evals by treating them
> pretty much as a slow running statement. There was no way to 'see inside'
> to see what code the string eval executed or how long it took.
> 
> The current trunk code treats evals pretty much as regular files.
> You can drill-down into string evals because each now gets its own
> report file (actually several files: line, block, sub, .dot etc).
> 
> That's great for 'interesting' evals, like those that define subs,
> but some apps execute thousands of 'uninteresting' evals.
> 
> I had planned to add code that would edit the data model to remove
> 'uninteresting' evals by treating them the old way, i.e., rollup
> the time within the eval to the statement that called it.
> 
> It turns out that it's fairly painful to edit the data structures
> to, for example, make sub calls from uninteresting evals appear
> to come from the line that called the eval.
> 
> So I'm now planning to compromise by defining 'uninteresting' more
> narrowly. An uninteresting eval is one that defines no subs, calls no
> subs and contains no string evals.

It turned out that "calls no subs" wasn't a viable compromise because
slowops mean practically all evals call 'subs'. So I've implemented
collapsing of string evals now, with all the data structure editing that
involved.

By collapsing multiple 'sibling' eval calls (i.e., calls on the same line)
into one eval, rather then try to 'roll up' all the evals into the caller,
it turned out to be not _too_ bad.

The code is ready for some real-world testing now.

Please give it a whirl, especially on code that uses string evals in
interesting ways...

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