Devel-StatProfiler

 view release on metacpan or  search on metacpan

MANIFEST  view on Meta::CPAN

68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
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

235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
        # 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 )