How Much Faster Is PyPy Compared to CPython?

Updated

PyPy 3.12 is, on average, about 4 times faster than CPython 3.11, according to the project's own homepage. That figure comes from benchmark times normalized to CPython, where smaller is better, and is backed by live data at speed.pypy.org. The gain comes from PyPy's Just-In-Time (JIT) compiler, which compiles hot Python code to machine code at runtime. The catch: 4x is an average across benchmarks, not a promise for your program — the real speedup depends heavily on what your code does.

Where the 4x Number Comes From

PyPy's homepage states the comparison directly: "On average, PyPy 3.12 is about 4 times faster than CPython 3.11." The accompanying chart normalizes PyPy (with JIT) benchmark times against CPython, so a bar at 0.25 means PyPy ran that benchmark in a quarter of CPython's time — a 4x speedup.

Two things to keep in mind about this number:

  • It is an average over a benchmark suite, not a single workload. Some benchmarks show much larger gains; others show little or none.
  • It is version-specific. The claim pairs PyPy 3.12 against CPython 3.11. PyPy currently supports Python 3.12, 3.11, and 2.7, so you can match your target Python version within that range.

You can check current results yourself at speed.pypy.org, which the homepage cites as the source of its live data.

Why PyPy Is Faster: The JIT Compiler

CPython interprets bytecode line by line. PyPy adds a JIT compiler that watches your program as it runs, identifies the loops and functions that execute most often ("hot" code), and compiles those paths down to machine code.

The practical consequences:

  • Long-running, loop-heavy programs benefit most. The JIT needs time to warm up and to learn which code is hot, so a script that runs for a few seconds may see little or no gain — and can even be slower during warm-up.
  • Short-lived scripts benefit least. If your program exits before the JIT has profiled and compiled anything meaningful, you pay the overhead without collecting the reward.
  • Memory-hungry programs may also improve. The homepage notes that programs using several hundred MB or more might end up taking less space than under CPython, though this is a separate effect from the JIT.

The Speedup Is Not Uniform

Because the 4x figure is an average, treat it as a starting hypothesis rather than a specification. A tight numerical loop with simple types is the classic best case for a JIT. Code dominated by C extensions, heavy I/O, or work already happening outside the interpreter will move much less, since the JIT only accelerates the Python-level portion.

This is why the honest answer to "how much faster?" is: measure your own workload. The official benchmark data tells you what is possible; it does not tell you what your specific program will do.

Compatibility: What You Can Run

PyPy is described as highly compatible with existing Python code, which matters because a speedup is worthless if your dependencies break. Per the homepage, PyPy:

  • Supports cffi and cppyy for C/C++ integration.
  • Runs popular libraries such as Twisted and Django.
  • Runs NumPy, Scikit-learn, and more through a C-extension compatibility layer.
  • Ships with stackless mode by default, providing micro-threads for massive concurrency.

The C-extension compatibility layer is the key detail: libraries that rely on C extensions can work, but they run through that layer rather than being JIT-compiled themselves, so their performance characteristics differ from pure-Python code.

Deciding Whether to Switch

Use these conditions to judge whether PyPy is likely to pay off for you:

Your situation Likely outcome
Long-running, CPU-bound, loop-heavy pure Python Best case — expect the largest gains
Short scripts that finish in seconds Little or no gain; warm-up overhead may hurt
Workload dominated by C extensions or I/O Modest gains at best; the JIT can't speed up what isn't Python
You depend on libraries needing C-extension support Verify they run via the compatibility layer before committing

A practical approach: pick your slowest, most CPU-bound code path, run it under both CPython and PyPy on the same machine, and compare. The homepage's own framing — "Python programs often run faster on PyPy" — uses "often" deliberately, because the JIT rewards some program shapes far more than others.

Where to Go Next

  • Download PyPy from pypy.org to test it against your own code.
  • Check live benchmark data at speed.pypy.org to see current per-benchmark results rather than the single 4x average.
  • Read the documentation (linked from the homepage) for installation and compatibility details before migrating a production project.

The headline number is real and sourced, but it is a benchmark average. The only speedup that matters for your decision is the one you measure on your own workload.