[Python-Dev] Optimization targets - refcount (original) (raw)

Phillip J. Eby pje at telecommunity.com
Fri Apr 16 08:40:11 EDT 2004

At 11:11 PM 4/15/04 -0700, Paul Prescod wrote:

Jewett, Jim J wrote:

Mike Pall:

About GC: yes, refcounting is the silent killer. ... PyDECREF is awful ... > 3500 locations Is it always needed? What if a few common (constant, singleton) objects (such as None, -1, 0, 1) were declared immortal at compile-time? They would be created at initial load in a special untracked pool, and their tpdealloc would do nothing. The slot for tracking references would still be there, but could be ignored -- even if it went negative. Since the reference count no longer has to be correct (for these objects), the reference counting macros could optimize to nothing when they know at compile time that they'll have one of these constant objects. So instead of writing PyDECREF(foo) would we write code like if(foo!=PyNone&&foo!=PyNeg1&&foo!=PyZero&&foo!=PyOne){ PyDECREF(foo); }

I think the idea is more that you could skip the 'Py_INCREF(Py_None)', which is a fairly common prelude to 'return Py_None'. You'd set their refcounts to the maximum possible value, and the deallocation function would simply reset the refcount to maximum again.

I'm not sure, however, that this would be common enough to be helpful. It seems to me Py_INCREF should effectively translate to only a single machine instruction or two. I mean, it's just incrementing an integer whose address is known at compile time.

More information about the Python-Dev mailing list