On Wed, Mar 04, 2009 at 12:53:36PM +0000, Nicholas Clark wrote: > > On Wed, Mar 04, 2009 at 12:49:19PM +0000, Tim Bunce wrote: > > > What I'm refering to in that note is the currently hidden cost of > > re-caching method lookups. Both ordinary methods where the cache is > > invalidated and repopulated on demand (if GvCVGEN(gv) != PL_sub_generation), > > and the overload method table which is recalculated for a package by > > Gv_AMupdate() > > if PL_sub_generation or PL_amagic_generation has changed. > > > > [That paragraph probably sounds like I know what I'm talking about. > > My internals foo is pretty rusty though, so don't be fooled :-] > > Yes, it is. In that
... ? > > All that's needed (I think) on the profiler side is for PL_sub_generation > > and PL_amagic_generation to be monitored for changes by NYTProf's > > DB_stmt() function. If either has changed since the last call then > > output a new tag. > > with 5.10.0, Brandon Black's work on Method Resolution Orders went live. > Part of this was to invalidate method caches on a package by package basis. > Whilst PL_sub_generation still exists, and still resets everything globally, > I believe that very little to nothing needs to bump it any more, as all code > has been updated to call an API to increase the generation on the package in > question (and all that package's children) So it's less important that it was because the impact of runtime sub creation/deletion is smaller. Okay. Any change to PL_amagic_generation? 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] -~----------~----~----~----~------~----~------~--~---
