On Fri, Dec 18, 2009 at 10:16:58PM +0000, Tim Bunce wrote: > On Fri, Dec 18, 2009 at 06:08:00PM +0000, Nicholas Clark wrote:
> > It has no tests yet - I was rather hoping that someone lurking would feel > > like that would make a good project to pay with. I meant "play". Thoughts about "pay" aren't relevant here. > (I'm hacking the testing framework to provide a very basic 'null merge' > test now - but that won't test _merging_ at all.) And I might be about to mess *that* part up, because: It turns out that real world code likes defining real subroutines inside eval blocks. (CGI, JSON::Any at least) Normally eval blocks always get new, distinct file IDs. But (I believe) that profiling data from the 2 (or more) definitions of the same subroutine should be merged. Which is great, except that you only learn of the definitions from a SUB_INFO at the *end* of each profile file, after all the TIME_LINEs and TIME_BLOCKs have been seen. So only then do you know how to properly map the file IDs for that profile file. So, I think, it's becoming necessary to stack up all the TIME_LINEs, TIME_BLOCKs (and SRC_LINEs) until the end of that file, then write them out with the correct file IDs. Only, that means that even a merge of 1 profile file will write it out in a different order. "all the right notes -- but not necessarily in the right order." This bit from Tim still stands: > Volunteers most welcome! Especially all the people who've asked > previously for the ability to merge files. Nicholas Clark -- 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]
