Python 3.15 benchmark: standard build inches ahead, experimental JIT pulls clearly in front

Miguel Grinberg has published the newest edition of his annual informal Python benchmark, and it landed on Hacker News's front page in early October. The run pits the Python 3.15.0rc3 release candidate — the final 3.15 release was still a few days away at the time of writing — against every CPython version back to 3.10, plus PyPy, Node.js and Rust. The short version: standard 3.15 is only slightly quicker than 3.14, but the experimental just-in-time compilation build has, for the first time in this benchmark's history, beaten the standard interpreter on both tests.

What was measured

The benchmark uses two small programs. The first, fibo.py, calculates the first 40 Fibonacci numbers using recursion, which Grinberg notes has historically been relatively inefficient in CPython. The second, bubble.py, sorts 10,000 randomly generated numbers with bubble sort using plain for-loops. I/O-bound code is deliberately excluded, and he stresses that the exercise is informal: it is meant to give a feel for version-to-version change, not a comprehensive performance profile of the interpreter.

Each configuration was run three times and averaged on a Gentoo Linux laptop with an Intel Core i5. macOS was dropped from the matrix this year after two previous runs showed no meaningful difference between operating systems. Alongside CPython 3.10 through 3.15, the tests cover the JIT and free-threading interpreter variants first shipped with 3.13, PyPy 3.12, Node.js 26.3 and Rust 1.97, each in single-threaded and four-threaded form. The figures below are the single-threaded results reported in the post.

Standard interpreter gains are modest

On the Fibonacci test, 3.15 finished in 6.94 seconds against 7.17 seconds for 3.14, a 1.03x difference Grinberg considers too small to matter in practice. The longer view is more interesting: 3.10 needed 15.94 seconds, so the standard interpreter is now roughly 2.3x faster than it was five versions ago on this workload.

The bubble sort test tells a similar story. 3.15 completed it in 1.97 seconds versus 2.06 seconds for 3.14, a 1.04x gain, and about 2x faster than 3.10's 3.99 seconds. Progress here is not strictly monotonic: 3.12 and 3.13 were each slightly slower than 3.11 on this test. Across both programs, Grinberg identifies 3.11 and 3.14 as the only recent releases that delivered significant leaps, with the others producing small improvements or holding steady.

The JIT build crosses over

The standout result of this year's run is the JIT. On the Fibonacci test, 3.15's JIT build finished in 5.76 seconds — 1.20x faster than the standard 3.15 interpreter and 1.24x faster than the 3.14 JIT. On bubble sort it took 1.54 seconds, 1.28x faster than standard 3.15 and 1.53x faster than the 3.14 JIT. In previous editions of the benchmark the JIT never managed to outpace the standard interpreter, so this crossover is the change Grinberg highlights as the most exciting finding.

Free-threading holds level

The free-threaded 3.15 build ran the Fibonacci test in 7.03 seconds, essentially matching both the 3.14 free-threaded build and the standard interpreter. On bubble sort it took 2.68 seconds, about 0.74x the speed of standard 3.15 — a deficit, but 3.14's free-threaded build showed a similar gap, so it is not a new regression. Since both reported tests are single-threaded, the parallelism that free-threading exists to enable is not exercised here anyway.

Against PyPy, Node and Rust

For context outside CPython, PyPy 3.12 completed the Fibonacci test in 1.25 seconds, 5.54x faster than 3.15, and the bubble sort in 0.11 seconds, 18.37x faster. Node.js 26.3 took 1.39 seconds on Fibonacci (4.99x) and 0.064 seconds on bubble sort (30.66x), meaning PyPy edged out Node on the recursive test while Node led on the loop-heavy one. Rust 1.97 finished in 0.09 and 0.039 seconds respectively, 77.24x and 50.42x faster than 3.15.

Why it matters

For teams already on 3.14, raw speed is not a compelling reason to rush the 3.15 upgrade — the standard interpreter's gains this cycle are marginal. The more consequential signal is the JIT crossover: an alternative build now consistently outperforming the standard interpreter on both tests suggests the JIT effort is maturing from curiosity toward something worth trialling for CPU-bound Python services, though it remains a separate build and these results say nothing about I/O-heavy real-world code. The cumulative picture since 3.10 — roughly 2x or better on both tests — also remains the strongest argument for keeping interpreter versions current. As Grinberg himself cautions, two synthetic programs are a directional indicator, not a profile; anyone with performance-sensitive workloads should measure their own code.