PEP 266: Optimizing Global Variable/Attribute Access
johnroth at ameritech.net
Wed Aug 15 20:18:06 CEST 2001
I'm all in favor of performance improvements, but maybe I'm missing
I just got back onto the NG after an absence of about 2 weeks, so I'm
not up on the prior discussion.
The issue seems to be that to find a variable, you have to search up the
entire static calling chain, using a dictionary lookup at each level until
you find the
object you've named. It seems like the expensive piece is the multi-level
using a dictionary lookup. If this could be speeded up, there wouldn't be
for a "tracking" mechanism, with the attendant complexities.
One way of making this faster would be to change the implementation of the
identifier lookup so that it used an array at all levels. The dictionary
contain identifier/index pairs instead of identifier/object pairs.
Each array entry would then contain a status code, an index and an object
The status is either "here", "deleted" or "forwarded". For "here", the
is what you want. For 'forwarded', the object points to the next object in
and the index specifies which identifier. "Deleted" has the obvious meaning.
There are some obvious complexities, like deleting an identifier requiring a
up the static chain to find out if there is another identifier that has just
"Skip Montanaro" <skip at pobox.com> wrote in message
news:mailman.997887028.29027.python-list at python.org...
> Skip> Actually, if I do it right, PEPTest2 would work more like
> Skip> def PEPTest2():
> Skip> m = math.sin
> Skip> c = 100000
> Skip> while c:
> Skip> l = 
> Skip> f = l.append
> Skip> for i in range(10):
> Skip> f(m(i))
> Skip> c -= 1
> Skip> That is, math.sin would get cached at the earliest point where
> Skip> is in scope, which would be before the while loop.
> After reading Alex's note on this subject I realized I may have
> misinterpreted what you asked for. While the PEP266 implementation will
> work about like the manual caching case, note that it will not change
> Python's semantics. If some other routine modifies the binding for
> during execution of the while loop, the PEPTest2 function will see the
> change, just as it would today if you included math.sin lookups in the
> and unlike the code above which statically binds m to the object referred
> by math.sin at the start of the function. That's the whole idea of the
> proposed TRACK_OBJECT/UNTRACK_OBJECT opcodes.
> Skip Montanaro (skip at pobox.com)
More information about the Python-list