PEP 266: Optimizing Global Variable/Attribute Access

[Skip Montanaro]

    John> The issue seems to be that to find a variable, you have to search
    John> up the entire static calling chain, using a dictionary lookup at
    John> each level until you find the object you've named. It seems like
    John> the expensive piece is the multi-level search using a dictionary
    John> lookup. If this could be speeded up, there wouldn't be any need
    John> for a "tracking" mechanism, with the attendant complexities.

    John> One way of making this faster would be to change the
    John> implementation of the identifier lookup so that it used an array
    John> at all levels. The dictionary would then contain identifier/index
    John> pairs instead of identifier/object pairs.

Even if you could replace all dicts with arrays, you'd still have to walk up
the chain.  That implies probably at least a few function calls.  In
addition, you seem to be suggesting replacing a dictionary with a dictionary
and a list.  If I ask for attribute "foo", you need to map "foo" to an array
index, then index the array to return the object bound to "foo".  You still
place the burden on the code that uses the object to look it up each and
every time.  My proposal places the onus on the code that updates the
object, so the client code can always just index into its fastlocals array
to get at an object.  If the object bound to the object I'm interested in
changed since the last time I accessed it, I know the relevant slot in
fastlocals as also been updated.

PEP 266 proposes to replace what is currently a fairly large number of
function calls with a single array lookup in the most common case.  It
should be a big win if I can handle the various corner cases and keep module
authors from blowing off their feet.

-- 
Skip Montanaro (skip at pobox.com)
http://www.mojam.com/
http://www.musi-cal.com/