[Python-Dev] Proposed PEP: Optimizing Global Variable and Attribute Access

[Skip Montanaro]

    Roman> Oh... Threads are mentioned only once in the end of PEP.  Another
    Roman> good question: what about generators? They aren't explicitly
    Roman> mentioned.  (And they are... err... potentioally active).

In my original thinking on the idea I gave some thought to threads, but then
convinced myself that the global interpreter lock was my friend.  Obviously,
if the GIL goes away, my assumptions won't hold and the various objects
involved in the tracking will have to be protected.

    Roman> If I understood correctly, tracked objects must be mostly applied
    Roman> to "constants". This assumption could lead to fast read. How fast
    Roman> write operation is is irrelevant.

Yes and no.  If I define a list:

    l = []

Then until l is bound to another object or goes out of scope it is
"constant".  "l.append" is also "constant" in this sense and is more
interesting to consider tracking because it is more expensive to look up in
the current scheme of things.

    Roman> I do not understand the following:

    Roman>     The number of tracked objects should be relatively small.
    Roman>     All active frames of all active threads could conceivably be
    Roman>     tracking objects, but this seems small compared to the number
    Roman>     of functions defined in a given application.

"relatively small" is a well... relative term.   The idea was to convey that
not every object will be tracked, only those with a potential payoff.  At
any one time, only objects associated with active PyFrameObjects will be
tracked, but it will not just be the top PyFrameObject of each thread's
stack.  It will be all the frame objects currently active for that thread.
Suppose I have 5,000 threads all executing this function:

    def foo():
        l = []
        for i in range(len(1000)):
            l.append(math.sin(i))
        return l

There are two objects potentially worth tracking: "l.append" and "math.sin".
I'm not sure the cost of slowing down every STORE_FAST instruction is worth
the cost savings of tracking "l.append" (it would probably no longer be just
an array store), but tracking "math.sin" would almost certainly be worth
it.  Note that if the binding of "math.sin" *did* change, the tracking for
5,000 copies of that name (one for each PyFrameObject in each thread) would
have to be updated.

    Roman> How small the number of tracked objects should be?  Will there be
    Roman> another arbitrary limit (like stack size)?  (Related ques: are
    Roman> there plans to remove stack-limit in Python?

No, there shouldn't be an arbitrary limit.  I assume that tracking will be
done using dictionaries.  This PEP does not concern itself directly with
stack issues, so I will defer that to someone like Christian Tismer who is
much better equipped to address such topics.

Skip