Your C-extensions come all bundled up with a whole lot of gorp which is designed to make them play nicely in a ref-counting environment. Ref counting is a very slow way to do GC. Sometimes -- really, 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.
There is a bit of conceptual confusion here -- on the one hand, because C extensions often were written for reasons of performance when compared to CPython, there is a tendency to believe that C-extensions are, pretty much by definition fast. And the other thing is a sort of reflexive belief that 'if it is in C (or C++) then it has to be fast'. Both of these ideas are wrong. A whole lot of C extensions are actually really, really slow. They are just faster than CPython -- or perhaps 'faster than CPython was when I wrote this thing' which isn't, after all, that hard a target to meet. When PyPy finds a C extension which is working very hard to pretend it is a set of Python objects that can be refcounted, it isn't brilliant enough to be able to throw away all the ref-counting fakery, intuit what the code here really is trying to do here, and just run that bit. That's too hard. Instead it decides to play along with the ref-counting faking. So we are at 'watch the elephant tap-dance' time ... it doesn't have to do a very good (read fast) job at this, it is amazing that it does it at all. Laura _______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
