[Python-Dev] Optimization targets - refcount

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.
>>>... Py_DECREF 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 tp_dealloc 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 Py_DECREF(foo) would we write code like
>
>if(foo!=Py_None&&foo!=Py_Neg1&&foo!=Py_Zero&&foo!=PyOne){
>         Py_DECREF(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