On Mon, Oct 27, 2008 at 03:03:02AM -0700, [EMAIL PROTECTED] wrote:
>
> Log:
> Add Devel::NYTProf::Data::Raw module
>
> This provides an interface for reading the raw profile data files.
> I just found this handy for understanding the file format and debugging
> it. It also opens up ways for creating alternative ways to summarize the
> data from Perl.
Thanks Gisle!
I'd envisaged this being implemented as a SAX provider. Any chance you
could rework it along those lines?
> +lib/Devel/NYTProf/Data/Raw.pm
I'd rather it was called Devel::NYTProf::ReadStream.pm as
Devel::NYTProf::Data::Raw doesn't convey much and the extra nesting
under Data is potentially confusing as it's not related to the ::Data
module (which itself isn't a great name).
> + if (cb) {
> + PUSHMARK(SP);
> + if (cb_seq) XPUSHs(sv_2mortal(newSViv(input_chunk_seqn)));
> + XPUSHs(sv_2mortal(newSVpvs("VERSION")));
> + XPUSHs(sv_2mortal(newSViv(file_major)));
> + XPUSHs(sv_2mortal(newSViv(file_minor)));
> + PUTBACK;
> + call_sv(cb, G_DISCARD);
> + }
Isn't this approach going to accumulate lots of unfreed mortal temps?
Rather than going the ENTER/sv_2mortal/LEAVE route I was thinking
of reusing a number of pre-allocated SVs. Would be much faster.
> + if (cb_seq) XPUSHs(sv_2mortal(newSViv(input_chunk_seqn)));
I think we could reuse $. (or some global of our own) for input_chunk_seqn.
> +=item PID_START => $pid, $parent_pid (v2.0)
> +
> +=item PID_START => $pid, $parent_pid, $start_time (v2.1)
> +
> +Still a mystery to me.
Dates from the way forking used to be supported. Likely to get
deprecated when we get better support for tracking the time the sub
profiler and stmt profiler were actually active. (Which is needed to
calculate percentages.)
> +=item TIME_BLOCK => $eval_fid, $eval_line, $ticks, $fid, $line,
> $block_line, $sub_line
> +
> +=item TIME_LINE => $eval_fid, $eval_line, $ticks, $fid, $line
> +
> +A TIME_BLOCK or TIME_LINE chunk is output each time the execution of
> +the program leaves a line.
> +
> +=item DISCOUNT
> +
> +Still a mystery to me.
Indicates that the next TIME_BLOCK or TIME_LINE should not increment the
"number of times the statement was executed". See the 'leave' option.
> +=item SUB_LINE_RANGE => $fid, $beg, $end, $name
> +
> +At the end of the run the profiler will output chunks that report on
> +the subroutines encountered.
This info comes straight from %DB::sub. See 'perldoc perldebguts'.
Outputs all subs, even if not executed, that are defined in fids
that did have a sub that was profiled.
> +=item SRC_LINE => $fid, $line, $text
> +
> +Not used (???)
Currenty only used for "perl -e '...'" and "perl -". They'll be an
option to control this. Including the ability to save the source code
(so reports are self-contained and don't get 'corrupted' by source code
changes that happen after the profile was run) and to save the source of
string evals. Either all, or just the first for any given eval statement.
Thanks for your work on this Gisle.
Tim.
p.s. I'd really appreciate it if you, and anyone else looking to
contribute significant functionality, could take a moment to discuss it
on the mailing list before getting into implementation work. That would
give us all a chance to kick around the ideas and get some rough
consensus, so work gets done in the best direction and without duplication.
Thanks!
--~--~---------~--~----~------------~-------~--~----~
You've received this message because you are subscribed to
the Devel::NYTProf Development User group.
Group hosted at: http://groups.google.com/group/develnytprof-dev
Project hosted at: http://perl-devel-nytprof.googlecode.com
CPAN distribution: http://search.cpan.org/dist/Devel-NYTProf
To post, email: [email protected]
To unsubscribe, email: [EMAIL PROTECTED]
-~----------~----~----~----~------~----~------~--~---
