Devel-StatProfiler
view release on metacpan or search on metacpan
686970717273747576777879808182838485868788t/011_switch_no_trampoline.t
t/013_fork.t
t/014_thread.t
t/016_disabled_api.t
t/017_stop_start.t
t/018_runtime_load.t
t/030_subs.t
t/031_begin.t
t/032_xsubs.t
t/033_goto.t
t/034_xsub_callbacks.t
t/035_eval_string.t
t/036_eval_block.t
t/037_lexical_subs.t
t/038_do.t
t/039_mapping.pl
t/040_tie.t
t/041_inner_runloop.t
t/050_source_traced_evals.t
t/051_source_all_evals.t
t/052_all_evals_always.t
lib/Devel/StatProfiler.pm view on Meta::CPAN
235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272
# 100 milliseconds of computation, then
goto
&foo
;
}
bar()
for
1..100000;
# foo.pl, line 10
will report that the code at F<foo.pl> line 10
has
spent approximately
the same
time
in calling C<foo> and C<bar>, and will report C<foo> as
being called from the main program rather than from C<bar>.
=head2 XSUBs with callbacks
Since XSUBs don't have a Perl-level stack frame, Perl code called from
XSUBs is reported as if called from the source line calling the XSUB.
Additionally, the exclusive time for the XSUB incorrectly includes the
time spent in callbacks.
=head2 XSUBs and overload
If an object has an overloaded C<&{}> operator (code dereference)
returning an XSUB as the code reference, the overload might be called
twice in some situations.
=head2 changing profiler state
Calling C<enable_profile>, C<disable_profile> and
C<stop_profile> from an inner runloop (including but not limited to
from C<use>, C<require>, C<sort> blocks, callbacks invoked from XS
code) can have confusing results: runloops started afterwards will
honor the new state, outer runloops will not.
Unfortunately there is no way to detect the situaltion at the moment.
=head2 source code and C<#line> directives
The parsing of C<#line> directive used to map logical lines to
physical lines uses heuristics, and they can obviously fail.
( run in 0.220 second using v1.01-cache-2.11-cpan-0d8aa00de5b )