On Wed, Dec 23, 2009 at 04:46:58PM +0000, Nicholas Clark wrote: > 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)
Yeah, I'm going to have to improve the reporting behaviour for subs defined in evals since PostgreSQL PL/Perl does that all the time. > 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. A key issue here is the precise definition of "same subroutine". For named subs we could use $subname + $fid + $firstlinenum + $lastlinenum as a key. For anon subs we could replace $fid with $eval_fid and $eval_line. Umm, for perls where the source of the sub is available we could even use the source code, or a hash of the source code, as the id. That seems like a very good idea. I've been thinking for a while that subs should be assigned unique abstract ids like files are. If the profiler did that itself we'd simplify the downstream processing considerably. (And the profiler could checksum the sub src even if savesrc is not enabled.) > 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. [I'm talking to myself for a couple of paras to get my head straight...] The subroutine profiler and the statement profiler are really quite distinct. TIME_LINEs, TIME_BLOCKs (and SRC_LINEs) are all the statement profilers domain. The subroutine profiler only thinks in terms of subroutine names and calls between them. SUB_INFO (%DBsub) is the link between the two profilers. The final reporting decides which fids to present and then, for each fid, it writes SRC_LINEs with the statement profile details (TIME_LINEs etc). Overlayed onto that is the subroutine profiler details which comes from the SUB_INFO (%DBsub) which gives us a name + fid + first & last line numbers. I think you could take the view that that's not your (merge) problem. nytprofmerge could be transparent to that and let whatever reads the final nytprof.out file handle that part of the merging (which it already does to a very limited extent). There's little difference between two more more definitions of the "same subroutine" coming from different evals in one nytprof file, vs definitions of the "same subroutine" in different files. > 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. The lack of tests is especially troubling as we're in a pretty murky area. > > Only, that means that even a merge of 1 profile file will write it out in > > a different order. > > And then all the discount statements go wrong. > The correct solution (seems) to be to read each profile file twice - building > the mapping on the first pass, using it on the second. > > (Which I'm about to commit) Thanks! 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]
