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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4