[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