Hi Laura, On 26 March 2014 23:29, Laura Creighton wrote:

really, really hideously slow. You are sometimes _way_ better off writing python code instead -- pypy with the jit turned off outperforms CPython purely on the benefits of not doing ref-counting, and pypy really needs the jit to be fast.

That detail is wrong. PyPy with the JIT turned off is 1.5x to 2x slower than CPython. (The reason is just the higher level of RPython versus hand-optimized C.) It is a common misconception to blame reference counting for the general slowness of standard interpreters of Python-like languages; I've seen it a few times in various contexts. But it's wrong: manual reference counting as in CPython doesn't cost much. This is probably because the reference counting increment/decrement end up as a very small fraction of the total runtime in this case. Also, the malloc() implementation used probably helps (it is very close to the one for the standard malloc() on Linux, which is really efficient for a lot of usage patterns). On the other hand, the reason PyPy doesn't include refcounting is that it's not reasonable at the level of the RPython implementation. Our RPython code assumes a GC *all the time*, e.g. when dealing with internal lists; by contrast, the CPython implementation assumes no GC and tries hard to put everything as stack objects, only occasionally "giving up" and using a malloc, like it is common in C. So incref/decref "everywhere in PyPy" means at many, many more places than "everywhere in CPython". In PyPy it is enough to kill performance completely (as we measured a long time ago). So I would say that the difference between refcounting and a "real GC" is that the latter scales nicely to higher levels of memory pressure than refcounting; but refcounting is fine if you can manually optimize where increfs are needed and where they are not, and if you manually avoid creating garbage as much as possible. A bientôt, Armin.