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:
Beforethesubroutinecall
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.
Makethesubroutinecall
The call is made by executing the original perl internal code for the "entersub" opcode.
Callingaperlsubroutine
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.
Callinganxsub
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.
Completingthemeasurement
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
Install Now
