view release on metacpan or  search on metacpan

MANIFEST  view on Meta::CPAN

t/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

        # 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.