At 10:00 PM 8/10/00 +0100, Graham Barr wrote:
>On Thu, Aug 10, 2000 at 04:54:25PM -0400, Dan Sugalski wrote:
> > At 08:31 PM 8/10/00 +0000, Nick Ing-Simmons wrote:
> > >You just re-invented "look up the name in a hash table" ;-)
> > >
> > >You now have one big hash table rather than several small ones.
> > >Which _may_ give side benefits - but I doubt it.
> >
> > If we prefigure a bunch of things (hash values of method names, store
> > package stash pointers in objects, and pre-lookup CVs for objects that are
> > typed) it'll save us maybe one level of pointer indirection and a type
> > comparison. If the object isn't the same type we pay for a type comparison
> > and hashtable lookup.
> >
> > Not free, but not expensive either. 'Specially if we get way too clever
> and
> > cache the new CV and type in the opcode for the next time around,
> presuming
> > we'll have the same type the next time through.
>
>Or if someone has defined a new sub, you don't know it was not the
>one you stashed.
A good point, if we've triggered AUTOLOAD. If we did store a pointer to the
sub, it'd have to be to the code ref in the packag stash, just in case
someone's gone and redefined the sub on us.
>I am not sure it got into perl5, but pre-computing the hash value of
>the method name and storing it in the op is one thing. Maybe also trying
>a bit harder to keep package hashes more flat.
Hmmm. Different hash function for package hashes? Maybe one that tends to
be flat for all word character names?
>Another thing that may help is if all the keys in package hashes are shared
>and also shared with constant method names in the op tree. Then when
>scanning the chain you only need do a pointer comparison and not a
>string compare.
Point. We should see about optimizing constant hash keys in general. I
think that may give us a bit of a performance boost.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
