[Python-Dev] Optimization targets - refcount

Mike Pall mikepy-0404 at mike.de
Sat Apr 17 17:50:00 EDT 2004


Hi,

Aahz wrote:
> On Fri, Apr 16, 2004, Mike Pall wrote:
> > To summarize: I think we can optimize the GC a little more (have not done
> > an in-depth analysis yet), but we really should focus on making Python
> > less malloc-happy. Suggestions welcome!
> 
> Could you expand on this?  What do you mean by "less malloc-happy"?
> What you were talking about earlier was ``None``, which doesn't go
> through malloc hoops.
> 
> I think you might find it useful to at least read old threads about
> refcounting vs. GC.  (I managed to dig up the old thread about getting
> rid of refcounting for ``None``; don't have time for more.)

I'm very well aware of the tradeoffs between refcounting and pure GC
schemes. I do *not* suggest that we change CPython's approach. And I do
not intend to start another refcount-vs-GC flamewar. You've got me wrong.

Also please check the thread -- I never suggested modifying anything
about Py_None. I just presented a short quantitative analysis that it's
useless to do so (the thread you referenced contains another good reason).

What I meant with 'less malloc-happy' is that we should try to reduce
the number of allocations/deallocations for internal (!) objects (I'm not
talking about objects explicitly managed by the application). Many of them
have a very short time-to-live. I guess some of them could be recycled or
even optimized away.

E.g. global profiling indicates that tuple allocation/deallocation has a
noticeable effect on performance. There are probably other objects that
have prohibitive setup/teardown cost (but are less pronounced on allocation
costs).

But since this is only #4 on my list I have not given it a closer look.
That's why I said 'suggestions welcome'.

Bye,
     Mike



More information about the Python-Dev mailing list