Making Python 3 more attractive

Posted Apr 17, 2015 0:44 UTC (Fri) by Cyberax (✭ supporter ✭, #52523)
In reply to: Making Python 3 more attractive by wahern
Parent article: Making Python 3 more attractive

> In fact, it tends to show that such systems should provide comparable performance when similarly optimized.
There's a catch, though. In real Python programs cycles are fairly rare and most of the objects are deallocated by the reference counting destructors.

So in practice quite often non-atomic reference counters might be faster than simple mark&sweep GC.

Making Python 3 more attractive

Posted Apr 17, 2015 1:18 UTC (Fri) by samlh (subscriber, #56788) [Link] (1 responses)

I agree that mark/sweep collectors are not universally the best option, for reasons of memory overhead, non-determinism, complexity, and so forth.

However, in the case of python, I am more willing to make the claim that mark/sweep collection would be beneficial performance-wise. I am basing this on PyPy's previous experimentation with different collection algorithms, including reference counting (with cycle collection, as required by Python). Their experience has led them, like the JS folk, to use a single-generational mark/sweep collector.

Regardless of the performance, though, I doubt that cPython should ever switch, simply due to the benefits of a stable c api. The answer to lack of Python 3 adoption is unlikely to be further breaking changes... though I admit I have no idea what is the answer.

Making Python 3 more attractive

Posted Apr 17, 2015 1:26 UTC (Fri) by samlh (subscriber, #56788) [Link]

My apologies for a possible misstatement above:
PyPy uses a single nursery generation and a tenured generation.
Spidermonkey (Firefox) is has some generational scheme (I'm fairly sure nursery+tenured).
I'm unsure of how V8 and Webkit have their gc structured.