Devel::NYTProf::Core(3User Contributed Perl DocumentatiDevel::NYTProf::Core(3)NAMEDevel::NYTProf::Core - load internals of Devel::NYTProf
DESCRIPTION
This module is not meant to be used directly. See Devel::NYTProf,
Devel::NYTProf::Data, and Devel::NYTProf::Reader.
While it's not meant to be used directly, it is a handy place to
document some internals.
SUBROUTINE PROFILER
The subroutine profiler intercepts the "entersub" opcode which perl
uses to invoke a subroutine, both XS subs (henceforth xsubs) and pure
perl subs.
The following sections outline the way the subroutine profiler works:
Before the subroutine call
The profiler records the current time, the current value of
cumulative_subr_secs (as initial_subr_secs), and the current
cumulative_overhead_ticks (as initial_overhead_ticks).
The statement profiler measures time at the start and end of processing
for each statement (so time spent in the profiler, writing to the file
for example, is excluded.) It accumulates the measured overhead into
the cumulative_overhead_ticks variable.
In a similar way, the subroutine profiler measures the exclusive time
spent in subroutines and accumulates it into the cumulative_subr_secs
global.
Make the subroutine call
The call is made by executing the original perl internal code for the
"entersub" opcode.
Calling a perl subroutine
If the sub being called is a perl sub then when the entersub opcode
returns, back into the subroutine profiler, the subroutine has been
'entered' but the first opcode of the subroutine hasn't been executed
yet. Crucially though, a new scope has been entered by the entersub
opcode.
The subroutine profiler then pushes a destructor onto the context
stack. The destructor is effectively just inside the sub, like a
"local", and so will be triggered when the subroutine exits by any
means. Also, because it was the first thing push onto the context
stack, it will be triggered after any activity caused by the
subroutines scope exiting.
When the destructor is invoked it calls a function which completes the
measurement of the time spent in the sub (see below).
In this way the profiling of perl subroutines is very accurate and
robust.
Calling an xsub
If the sub being called is an xsub, then control doesn't return from
the entersub opcode until the xsub has returned. The profiler detects
this and calls the function which completes the measurement of the time
spent in the xsub.
So far so good, but there's a problem. What if the xsub doesn't return
normally but throws an exception instead?
In that case (currently) the profiler acts as if the xsub was never
called. Time spent inside the xsub will be allocated to the calling
sub.
Completing the measurement
The function which completes the timing of a subroutine call does the
following:
It calculates the time spent in the statement profiler:
overhead_ticks = cumulative_overhead_ticks - initial_overhead_ticks
and subtracts that from the total time spent 'inside' the subroutine:
incl_subr_sec = (time now - time call was made) - overhead_ticks
That gives us an accurate inclusive time. To get the exclusive time it
calculates the time spent in subroutines called from the subroutine
call we're measuring:
called_sub_secs = cumulative_subr_secs - initial_subr_secs
and subtracts that from the incl_subr_sec:
excl_subr_sec = incl_subr_sec - called_sub_secs
To make that easier to follow, consider a call to a sub that calls no
others. In that case cumulative_subr_secs remains unchanged during the
call, so called_sub_secs is zero, and excl_subr_sec is the same as
incl_subr_sec.
Finally, it adds the exclusive time to the cumulative exclusive time:
cumulative_subr_secs += excl_subr_sec
AUTHOR
Tim Bunce, <http://www.tim.bunce.name> and <http://blog.timbunce.org>
COPYRIGHT AND LICENSE
Copyright (C) 2008, 2009 by Tim Bunce.
This library is free software; you can redistribute it and/or modify it
under the same terms as Perl itself, either Perl version 5.8.8 or, at
your option, any later version of Perl 5 you may have available.
perl v5.14.2 2012-08-11 Devel::NYTProf::Core(3)
