On Wed, Feb 03, 2010 at 01:49:22PM +0000, Nicholas Clark wrote:
> On Thu, Dec 17, 2009 at 09:13:44PM +0000, Tim Bunce wrote:
>
> > Attributes probably need a little more logic.
> > Some should be output immediately:
> > ticks_per_sec, profiler_start_time, profiler_end_time
> > For the rest I'd suggest doing
> > $attr->{$key}{$value}++;
> > here.
> >
> > In the code to finalize the file, output any attributes that only have a
> > single distinct value. Any with more that one...
> > application: join with " and "
> > basetime: min(...)
> > clock_id: croak
> > complete: warn, output 0
> > perl_version: warn, output min
> > profiler_start_time: output min
> > profiler_end_time: output max
> > profiler_duration: discard
> > xs_version: croak
> > ...others...: croak
>
> Others are:
>
> ARCHLIB_EXP PL_perldb PRIVLIB_EXP nv_size ticks_per_sec
>
> which make sense for consistence. Except that as 'ARCHLIB_EXP' and
> 'PRIVLIB_EXP' both contain the perl version with them, that effectively means
> that different 'perl_version' attributes will always croak anyway.
Ok.
> I assume that it's sane to put the 'application' and 'basetime' attributes at
> the end of the profile file, as nothing (as best I can see) currently relies
> on them.
Only for reportin
> 'profiler_duration' isn't actually written out - it's calculated from
> 'profiler_end_time' - 'profiler_start_time'.
[Aside: The time tracking is a bit of a mess at the moment. There's a
conceptual issue relating to percentages that needs to be explored.
In order to show a percentage, like the percentage of time spent in a
subroutine, we need a total. The total time is easy if the profiler was
enabled for the full duration, as it usually is. But what should be
reported if the profiler was only enabled for short periods?
Making enable_profile and disable_profile write timestamped tags into
the stream to be a good start. It's not a priority though.]
> In turn, those two aren't actually
> attributes - they're written as part of NYTP_TAG_PID_START and
> NYTP_TAG_PID_END. (Which makes sense, as it means that the profile format
> already copes with representing data from multiple runs.
An artifact from the days when forking was handled with multiple
processes locking and writing to the same file.
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]
