On Tue, Oct 28, 2008 at 07:12:13PM +0100, Gisle Aas wrote:
> On Tue, Oct 28, 2008 at 17:12, Tim Bunce <[EMAIL PROTECTED]> wrote:
> > On Tue, Oct 28, 2008 at 09:24:50AM +0100, Gisle Aas wrote:
> >> On Mon, Oct 27, 2008 at 21:35, Tim Bunce <[EMAIL PROTECTED]> wrote:
> >> > I'd envisaged this being implemented as a SAX provider. Any chance you
> >> > could rework it along those lines?
> >>
> >> What do you mean by SAX provider? You want it to actually be
> >> compatible with XML::SAX and call out to the XML::SAX::Base interface?
> >
> > I hadn't thought about it much beyond a vague desire to call different
> > methods for different tags. Now I've given it some thought I'd say it's
> > inappropriate for the low-level interface (but the low-level interface
> > shouldn't make it hard/slow to add a SAX interface on top).
>
> Converting the current interface to one that calls different methods
> for each chunk is trivial.
>
> for_chunks {
> my $tag = shift;
> $obj->$tag(@_);
> }
>
> converting the other way a bit more work. Might be possible to
> support both directly from the XS code by switching on the SvTYPE of
> the callback param.
That sounds better from a performance point of view.
Though it occurs to me that the performance concerns all relate to the
very high volume statement timing data. It would be helpful to have some
easy way for the caller to indicate that statement timing data is or
isn't wanted. So those that don't want it aren't slowed down by the high
cost of firing the callback for them.
That also ties-in with the sub call 'punctuation' idea. It should be
possible to turn on and off the statement timing data callbacks when
entering/leaving subs of interest.
Perhaps when calling for_chunks() pass in ref to a hash where the keys
are tags and the values indicate if the callback should be fired for
that tag. (The load_profile_data_from_stream() loop could cache those
value SVs so the lookup would be very cheap.) The hash could be altered
dynamically to enable
Taking that a step further, the hash keys could be code refs.
Another thought: add an option to not call the callback for the incoming
raw statement times, but instead fire the callback on the aggrated data
once the profile has been loaded.
> > As an aside... one of the reasons I hadn't implemented a streaming/event
> > based api was that I doubted how useful it would be for the raw data.
> > The raw data is very raw in many ways, especially when trying to make
> > sense of string evals (as you've seen from my recent checkins).
>
> One idea I had would be to plot a density diagram which would plot all
> the source lines on the Y axis against time on the X and then scale it
> all down to fit on a single page. The idea would be that this would
> display how control moves through the sources over time and make it
> clear how hotspots in the code move at different phases of the
> program. I think it might be a cool view. Not sure if it's really
> useful.
Me neither. Cool though, like you say. Our aim here should be to lower
the barriers to letting people experiment with this data.
It's crossed my mind a few times that a tree-map representation with
nested file->package->sub->block->line areas could be very useful.
[Uh, now I look into it again I see Devel::WxProf has treemaps
http://search.cpan.org/~mkutter/Devel-WxProf/lib/Devel/WxProf/Treemap/Squarified.pm
so that may be where I got the idea from.]
> > One thing that might help would be to have the sub profiler emit some
> > data into the stream when subs are entered and left. That would act as
> > useful 'punctuation' in the fast flowing stream of statement timings.
>
> Right, seems like a good idea. Another idea would be to also output
> chunks about how much memory is allocated at different times.
There's a note in HACKING about that:
: Could optionally track resource usage per sub. Data sources could be
: perl sv arenas (clone visit() function from sv.c) to measure number of
: SVs & total SV memory, plus getrusage()). Abstract those into a
: structure with functions to subtract the difference. Then use the same
: logic to get inclusive and exclusive values as we use for inclusive and
: exclusive subroutine times.
That's potentially very powerful.
> >> > 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).
> >>
> >> I think we can wait with revising the name until the interface has
> >> found its form. To me the ::Data part means the 'nytprof.out' file
> >> format basically, so in that way I found the name logical. I started
> >> out with a class method on the ::Data class, but it did feel right so
> >> I decided to just create a submodule instead.
> >
> > I see the ::Data classes (there's ::Data::ProfFile and ::Data::ProfSub
> > inside Data.pm - they'll be split out at some point) as relating to the
> > evolving data model.
After more consideration I'd really like the ::Data::Raw module renamed
to ::ReadStream sooner rather than later. The interfaces it offers can
grow and evolve in and under that namespace. The longer it's left the
harder it'll get to change the name.
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]
-~----------~----~----~----~------~----~------~--~---
