>>>>> "GB" == Graham Barr <[EMAIL PROTECTED]> writes:
GB> 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.
GB> Or if someone has defined a new sub, you don't know it was not the
GB> one you stashed.
Leave a stub behind at the old address that would trigger the repointing.
(I'm not clear what to do for refcounting the old address)
GB> I am not sure it got into perl5, but pre-computing the hash value of
GB> the method name and storing it in the op is one thing. Maybe also trying
GB> a bit harder to keep package hashes more flat.
GB> Another thing that may help is if all the keys in package hashes are shared
GB> and also shared with constant method names in the op tree. Then when
GB> scanning the chain you only need do a pointer comparison and not a
GB> string compare.
I don't think anything should be in the op tree. The optree (or whatever
the engine is) should only be operations. Data should be either in the
object, vtbl, or stack.
<chaim>
--
Chaim Frenkel Nonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
