On Tue, Jan 19, 2010 at 12:04:58PM +0000, Nicholas Clark wrote: > I'm trying to get the merging more reliable. One problem is that there is some > variance in which Perl files XS subroutines are assigned to. XSUBs don't > carry filenames, so NYTProf tries to find "homes" for them by scanning > %DB::sub, the debuggers subroutine->filename mapping hash, to identify > (Perl) subroutines in the same package, and hence get a filename for them. > > I've added a heuristic in r1015 to deal with one case I'd found - JSON::XS > adds :lvalue to one of its XSUBs in its BOOT: section, which causes the > interpreter to autoload attributes, which results in entry in %DB::sub for > DynaLoader::BEGIN in .../JSON/XS.pm.
Ouch. > I can spot that because the line range is illegal. > > The problem remaining is that sometimes the XSUB Storable::bootstrap is > attributed to .../Storable.pm, and sometimes to (eval 7)[.../Storable.pm] > > It all depends on the order that %DB::sub returns results when it iterates. Not good. > So I *assumed* that if I made that code skip anything that matches the > eval "filename" pattern, it would solve this: > > However, it seems that this approach makes several unrelated tests fail: > I'm not sure if this is because they are all assuming golden results, and > I've just changed the ordering, or there is a more serious problem. My > assumption was that any "eval" filename that exists has a corresponding > real file to go with it, and that *that* file would get spotted later on > in the %DB::sub iteration. So I'm not sure what to do here. Skipping "eval" > filenames seems conceptually cleaner, but I don't understand *why* it causes > breakage. Are you having fun yet? :) > I added some logging to track every mapping generated by the each %DB::sub > loop in write_sub_line_ranges > > fprintf(log, "%.*s => %.*s\n", (int)sub_name_len, sub_name, > (int)filename_len, filename); > > The full diff has 4 hunks with a lot of lines repeated and is easily > skimmable: > -main::__ANON__[(eval 1)[test11.p:3]:1] => (eval 1)[test11.p:3] > +main::BEGIN => test11.p > -main::__ANON__[(eval 1)[test22-strevala.p:6]:1] => (eval > 1)[test22-strevala.p:6] > +main::BEGIN => test22-strevala.p > -main::sub9 => (eval 9)[test51-enable.p:7] > +main::BEGIN => test51-enable.p > -main::__ANON__[(eval 3)[test61-submerge.p:8]:1] => (eval > 3)[test61-submerge.p:8] > +main::foo => test61-submerge.p > ie the proposed change means *only* that package main:: in 4 cases goes > > * from being mapped to a file name generated by an eval > * to being mapped to a file name on disk > > which feels *right*. > > So now I feel that I need to work out what the diff against all the test > results actually means. > > Or should I just force the issue, by assuming that the new "got" is what > "expected" should be? Go ahead. When life gets too short, and the results seems sane, I've done that myself many times before ;-) Tim. p.s. I'm going to have to revisit the handling of string evals in reports soonish anyway. nytprofhtml doesn't handle cases where subroutines have been defined by string evals. PostgreSQL PL/Perl creates it's subs that way, so currently you can't view the profile of the code in those subs.
-- 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]
