I'm hoping that someone with knowledge of Perl internals can shed some light on a puzzle.
I've found a case where having AUTOLOAD dynamically generate a getter method is actually slower (by ~5% over the course of a test run) than doing the getter in-line in AUTOLOAD. The situation is one where a frequently overridden abstract base class supplies an AUTOLOAD for handling simple getters. (The AUTOLOADed name turns into a hash key lookup on the instance, provided the key exists.) I noticed that this AUTOLOAD was getting called about 900K times during the course of a test run, and tried optimizing it by generating new getter methods on demand. This reduced the number of calls to AUTOLOAD to a few thousand, but performance got slightly worse.
I suspect that this has to do with Perl's method caching, whereby the result of a method lookup is cached such that subsequent lookups are faster. I puzzled through the code a few years ago. It looked like the cache got flushed whenever the symbol table was manipulated. If that's the case, it might explain why my tests got slower: the random generation of new getter methods caused the lookup cache to be flushed and subsequently regenerated, more than offsetting the benefit of not having to fall all the way back on AUTOLOAD for frequent getter calls. But I may have misread or misunderstood the code.
Does this sound plausible? Has anyone run into this before (and maybe written it up)?
In reply to An AUTOLOAD performance puzzler by dws
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |