Hi Laura,

On 26 March 2014 23:29, Laura Creighton <lac@openend.se> 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).