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