Hi Laura, On 29 March 2014 09:52, Laura Creighton <lac@openend.se> wrote:

Ok -- the lesson I took from this is 'ref counting hurts performance'. Why was that the wrong inference to make?

No, the lession is "unoptimized refcounting hurts performance". As I've explained above, optimized refcounting like in CPython seems to be good enough for almost all use cases, with the sole known exception being some cases of gcbench.py. I think that since this 2007 report we never were really interested enough to know the details more precisely. If someone wants to go to the bottom of the question, he'd need to write an automatic optimizer to remove most incref/decref in PyPy, and add a cycle detector. Or do the opposite: scrap reference counting in CPython and replace the Py_Incref/Py_Decref with, say, shadow stack saving/restoring (search for _du_save/_du_restore in https://bitbucket.org/pypy/stmgc/raw/default/duhton for an example). Either way, it looks unlikely that he'd get something that is either simpler or more performant (here I'm ignoring CPython+Psyco which muddles the picture). I think that each of CPython and PyPy have right now the kind of GC that is best suited for them. A bientôt, Armin.

Hi Laura, On 29 March 2014 09:52, Laura Creighton <lac@openend.se> wrote:

Ok -- the lesson I took from this is 'ref counting hurts performance'. Why was that the wrong inference to make?

No, the lession is "unoptimized refcounting hurts performance". As I've explained above, optimized refcounting like in CPython seems to be good enough for almost all use cases, with the sole known exception being some cases of gcbench.py. I think that since this 2007 report we never were really interested enough to know the details more precisely. If someone wants to go to the bottom of the question, he'd need to write an automatic optimizer to remove most incref/decref in PyPy, and add a cycle detector. Or do the opposite: scrap reference counting in CPython and replace the Py_Incref/Py_Decref with, say, shadow stack saving/restoring (search for _du_save/_du_restore in https://bitbucket.org/pypy/stmgc/raw/default/duhton for an example). Either way, it looks unlikely that he'd get something that is either simpler or more performant (here I'm ignoring CPython+Psyco which muddles the picture). I think that each of CPython and PyPy have right now the kind of GC that is best suited for them. A bientôt, Armin.