>>>>> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> Dan concluded:
>> Certainly doable. Just potentially slow, which is what I'm worried
>> about. Making it not slow has both potential significant complexity
>> and memory usage. If we have to, that's fine. Just want to make
>> sure the cost is known before the decision's made. :)
DC> I rather liked the
DC> "delete-means-install-a-pad-walking-placeholder" notion. That way
DC> things only get slow if you actuallt do something evil.
but that doesn't cover adding something into the parent scope. that
can't fit into the pad since it was preallocated and has no slot for the
new symbol. maybe then a hash based pad is added and checked
first/last. again, this is a majro slowdown.
even with a linear pad, if a lower scope references a parent, it has to
do a linear search. what about a similar idea to the above, add a hash
based pad whenever the pad set of symbols is changed (deletes or
additions). the original pad is still used for code compiled in the
pad's scope so those vars are always found with a pad offset and are
fast. the first time you do something to a pad from another scope, a
hash of it is made and attached to the pad. that hash is used for all
external access to %MY::.
seems like a win as it only penalizes the users of %MY:: in another
scope and which modify its symbol table. and then the hash is a speedup
for later uses of that pad.
another way to look at it is that compiled code in a scope uses compile
time pad offsets and external access to a pad at runtime is via a
hash. the hash entries for the compiled symbols refer to pad offsets and
the others are stored in the hash itself.
i can't believe i got sucked into this thread. :)
uri
--
Uri Guttman --------- [EMAIL PROTECTED] ---------- http://www.sysarch.com
SYStems ARCHitecture and Stem Development ------ http://www.stemsystems.com
Search or Offer Perl Jobs -------------------------- http://jobs.perl.org
