Performance

One of the goals of the PyPy project is to provide a fast and compliant python interpreter. Some of the ways we achieve this are by providing a high-performance garbage collector (GC) and a high-performance Just-in-Time compiler (JIT). Results of comparing PyPy and CPython can be found on the speed website. Those benchmarks are not a random collection: they are a combination of real-world Python programs – benchmarks originally included with the (now dead) Unladen Swallow project – and benchmarks for which we found PyPy to be slow (and improved). Consult the descriptions of each for details.

The JIT, however, is not a magic bullet. There are several characteristics that might surprise people who are not used to JITs in general or to the PyPy JIT in particular. The JIT is generally good at speeding up straight-forward Python code that spends a lot of time in the bytecode dispatch loop, i.e., running actual Python code – as opposed to running things that only are invoked by Python code. Good examples include numeric calculations or any kind of heavily object-oriented program. Bad examples include doing computations with large longs – which is performed by unoptimizable support code. When the JIT cannot help, PyPy is generally slower than CPython.

More specifically, the JIT is known not to work on:

  • Tests: The ideal unit tests execute each piece of tested code once. This leaves no time for the JIT to warm up.
  • Really short-running scripts: A rule of thumb is if something runs below 0.2s the JIT has no chance, but it depends a lot on the program in question. In general, make sure you warm up your program before running benchmarks, if you're measuring something long-running like a server. The time required to warm up the JIT varies; give it at least a couple of seconds. (PyPy's JIT takes an especially long time to warm up.)
  • Long-running runtime functions: These are the functions provided by the runtime of PyPy that do a significant amount of work. PyPy's runtime is generally not as optimized as CPython's and we expect those functions to take somewhere between the same time as CPython to twice as long. This includes, for example, computing with longs, or sorting large lists. A counterexample is regular expressions: although they take time, they come with their own JIT.

Unrelated things that we know PyPy to be slow at (note that we're probably working on it):

  • Building very large dicts: At present, this is an issue with our GCs. Building large lists works much better; the random order of dictionary elements is what hurts performance right now.
  • CPython C extension modules: Any C extension module recompiled with PyPy takes a very large hit in performance. PyPy supports C extension modules solely to provide basic functionality. If the extension module is for speedup purposes only, then it makes no sense to use it with PyPy at the moment. Instead, remove it and use a native Python implementation, which also allows opportunities for JIT optimization. If the extension module is both performance-critical and an interface to some C library, then it might be worthwhile to consider rewriting it as a pure Python version that uses something like ctypes for the interface.
  • Missing RPython modules: A few modules of the standard library (like csv and cPickle) are written in C in CPython, but written natively in pure Python in PyPy. Sometimes the JIT is able to do a good job on them, and sometimes not. In most cases (like csv and cPickle), we're slower than CPython, with the notable exception of json and heapq.
  • Abuse of itertools: The itertools module is often “abused” in the sense that it is used for the wrong purposes. From our point of view, itertools is great if you have iterations over millions of items, but not for most other cases. It gives you 3 lines in functional style that replace 10 lines of Python loops (longer but arguably much easier to read). The pure Python version is generally not slower even on CPython, and on PyPy it allows the JIT to work much better – simple Python code is fast. The same argument also applies to filter(), reduce(), and to some extend map() (although the simple case is JITted), and to all usages of the operator module we can think of.
  • Ctypes: Ctypes is a mixed bunch. If you're lucky you'll hit the sweetspot and be really fast. If you're unlucky, you'll miss the sweetspot and hit the slowpath which is much slower than CPython (2-10x has been reported).

We generally consider things that are slower on PyPy than CPython to be bugs of PyPy. If you find some issue that is not documented here, please report it to our bug tracker for investigation.