On Sun, Jan 11, 2009 at 11:06:18PM -0500, David Steinbrunner wrote:
> Tim Bunce wrote:
>
> > p.p.s A good first step would be to add a stub
> > merge_profile_data_from_file()
> > method and update nytprofhtml to use it. Perhaps via a
> > Devel::NYTProf::Data->new_merged({ files => \...@files }) method that
> > calls load_profile_data_from_file() for the first and
> > merge_profile_data_from_file() for the rest.
>
> I started down this path. In the process this *feeling* that having the
> normal constructor modified to handle the merging would be best. Here is a
> snippet what I have to give you an idea:
>
> print "Reading $file\n" unless $args->{quiet};
>
> my $profile = load_profile_data_from_file($file);
> bless $profile => $class;
>
> foreach (@{$args->{filenames}}) {
> print "Reading $_\n" unless $args->{quiet};
> $profile->merge_profile_data_from_file($_);
> }
>
> my $fid_fileinfo = $profile->{fid_fileinfo};
> my $sub_subinfo = $profile->{sub_subinfo};
>
> Is this workable and hopefully better than your suggestion or am I off base
> here.
Sure. The real issue is how the arguments are passed in. We don't have
to worry about backwards compatibility so I'd suggest we simply replace
the current { filename => $file } parameters with { filename => [...] }
and call load_profile_data_from_file() on the first.
> It seemed like the fileinfo and subinfo work being done from that
> point on would need to be done on all the data so getting the data together
> before that would be best. Of course, at this point I have yet to figure
> out what all the fileinfo and subinfo code is about or what should be really
> be happening in my empty merge_profile_data_from_file so I'm kind of
> shooting in the dark here.
To make matters worse, much of it is in a state of flux.
Probably all the remaining code in new() will disappear soonish.
The bless'ing will move into the XS code and the merging of
"anon subs created at the same line of the same eval" will
also happen in XS once I pluck up the courage to enable
normalize_eval_seqn() and deal with the fallout from that.
> I should likely start following your advise about profiling to find out
> about each kind of data here soon like...
Yeap :)
Let's start with attributes. For each one you'll need to opt for one of
these behaviours (off the top of my head):
use the sum()
(total_stmts_duration total_stmts_measured total_stmts_discounted
total_sub_calls)
use the max()
(profiler_end_time)
use the min()
(profiler_start_time)
warn if something should match but doesn't
(basetime)
die if something should match but doesn't
(xs_version perl_version clock_id ticks_per_sec nv_size)
We can start by being very restrictive, focussing just on the
fork/mod_perl use case. In which case a difference basetime should die.
The semantics of attributes like profiler_duration may need some thought
(because I can't remember what they are off the top of my head :)
It might be a good idea to start a new thread to discuss each of the
top-level profile elements, starting with a new thread for attributes.
Tim.
--~--~---------~--~----~------------~-------~--~----~
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]
-~----------~----~----~----~------~----~------~--~---
