PEP 266: Optimizing Global Variable/Attribute Access

[John Roth]

I'm all in favor of performance improvements, but maybe I'm missing
something here?
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
search
using a dictionary lookup. If this could be speeded up, there wouldn't be
any need
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
would then
contain identifier/index pairs instead of identifier/object pairs.

Each array entry would then contain a status code, an index and an object
reference.
The status is either "here", "deleted" or "forwarded". For "here", the
object reference
is what you want. For 'forwarded', the object points to the next object in
the chain,
and the index specifies which identifier. "Deleted" has the obvious meaning.

There are some obvious complexities, like deleting an identifier requiring a
search
up the static chain to find out if there is another identifier that has just
become unshielded.

John Roth

"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
it
>     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
math.sin
> 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
loop
> and unlike the code above which statically binds m to the object referred
to
> 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)
> http://www.mojam.com/
> http://www.musi-cal.com/
>