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.
>> >> +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).
>>
>> 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.
>
> 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.
> 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.
--Gisle
--~--~---------~--~----~------------~-------~--~----~
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]
-~----------~----~----~----~------~----~------~--~---
