Python's JIT Compiler in Mid-2026: What the Numbers Actually Say and When You Should Care

CPython 3.15 shipped a just-in-time compiler, and the Python community spent the weeks that followed trying to figure out whether to be excited. The answer, as of mid-July 2026, is a qualified yes. The JIT delivers real speedups on real code. It also falls well short of what alternative Python runtimes have been doing for years, and it has a list of caveats long enough to make any production engineer pause.

Here is where things stand, what the benchmarks actually show, and when the JIT is worth caring about.

The numbers: 8 to 13 percent, sometimes more, sometimes less

The JIT’s headline performance is modest but real. On x86-64 Linux, the geometric-mean speedup across CPython’s benchmark suite is roughly 8 to 9 percent. On AArch64 macOS, likely due to architectural differences in how the JIT’s generated code interacts with Apple Silicon, the number climbs to 12 to 13 percent ¹.

Those are averages. Individual benchmarks tell a messier story. Some workloads speed up by more than 100 percent. Others slow down by 15 percent. The variance is wide enough that you cannot assume the JIT will help your specific code without testing it on your specific workload. A web framework routing hot path and a NumPy-heavy data pipeline may see completely different results, and the only way to know is to measure ¹.

JIT lead Ken Jin has floated a long-term target of around 20 percent speedup, describing it as “one-half to one-quarter of PyPy.” For context, contributors measured PyPy at roughly 50 percent faster than CPython 3.15 on macOS and 80 to 90 percent faster on x86-64 Linux. Even the JIT’s optimistic 20 percent target barely dents PyPy’s lead, and today’s single-digit gains leave it well short of either mark ¹.

Why the gap with PyPy is so large

PyPy has been working on its JIT for over 15 years. CPython’s JIT is less than two years old in any meaningful form. The gap in maturity is the gap in performance. PyPy’s tracing JIT observes which code paths are actually hot at runtime and specializes aggressively for those paths, inlining function calls, unrolling loops, and applying type specializations that eliminate the overhead of Python’s dynamic type system for the specific types that appear in practice. CPython’s copy-and-patch JIT is a simpler design: it generates templated machine code for individual bytecode instructions and stitches them together. It does not do inter-instruction optimization. It does not specialize based on runtime types. It is faster to compile, easier to maintain, and produces less dramatic speedups.

The design trade-off was intentional and well understood by everyone involved. The CPython team prioritized maintainability and predictability over raw speed. A complex tracing JIT in the reference implementation would create a maintenance burden that the core team, which is already stretched thin, could not realistically sustain. The copy-and-patch approach delivers a meaningful if unspectacular improvement while keeping the compiler simple enough that contributors can understand, debug, and modify it without becoming JIT specialists.

Whether that trade-off was the right one depends on what you want from CPython. If you need the fastest possible Python runtime today, PyPy is still the answer — assuming your dependencies are compatible. If you want a modest, low-risk speedup that comes built into the interpreter you are already using, with zero changes to your code or your deployment pipeline, the JIT delivers exactly that. For most production Python workloads, an automatic 10 percent speedup with no engineering investment is a better deal than a potential 50 percent speedup that requires testing every dependency for PyPy compatibility and maintaining a separate runtime in your CI pipeline.

The free-threading problem

The JIT currently disables itself the moment you start threads. It does not work with Python’s free-threaded mode, the other major performance initiative that shipped in 3.13 and has been gradually improving since. Making those two flagship projects work together is a significant engineering challenge, and one that any PEP formalizing the JIT’s future will need to address ¹.

This is not a small footnote. If you are using Python for I/O-bound workloads with threading, or if you have been waiting for free-threaded Python to mature so you can drop the GIL-shaped workarounds in your codebase, the JIT offers you nothing right now. The Venn diagram of “code that benefits from the JIT” and “code that benefits from free threading” currently has zero overlap.

The core team is aware of this. Discussions about a formal PEP for the JIT’s maintenance plan and long-term roadmap are ongoing, and the free-threading compatibility question is high on the list of issues that need resolution before the JIT can be considered for a default-on status. The council wants a clear-eyed plan before it commits, and forcing that conversation now, rather than after the JIT is on by default, is widely seen as a healthy moment for the project ¹.

What else shipped recently

The JIT is not the only performance story in Python’s mid-2026 landscape. A few other updates worth noting:

PyPy 7.3.23 landed with a reworked bytecode interpreter that uses exception tables instead of dedicated opcodes, bringing its disassembly output closer to CPython’s. This is more of a maintainability improvement than a performance one, but it matters for anyone who debugs at the bytecode level ¹.

Polars 1.41 shipped a hand-written Thrift decoder for Parquet metadata that runs up to 3.3 times faster on very wide tables. It also brings smarter query-plan optimization and a lazy LazyFrame.gather method for selecting rows by index without forcing materialization. If your Python performance bottleneck is data processing rather than interpreter overhead, Polars continues to deliver bigger wins than any JIT can promise. A 3.3x improvement on Parquet reads for wide tables is the kind of gain that makes a 10 percent interpreter speedup look like a rounding error ¹.

CPython 3.15.0b4 was released on July 18, continuing the beta cycle toward the final 3.15 release expected later this year. If you have not tested your code against 3.15 yet, now is the time. The JIT is not the only change in 3.15, and some of the other changes — particularly around the type system and standard library deprecations — may matter more for your specific codebase than a single-digit performance improvement ¹.

When you should care

If you run CPU-bound Python code in single-threaded mode on CPython 3.15, the JIT will make your code somewhere between slightly and moderately faster, for free, with no code changes. You should enable it. There is essentially no reason not to, unless your specific workload hits one of the benchmarks that regresses by 15 percent, in which case you should measure before you decide.

How to test this on your own codebase: install CPython 3.15 beta, run your test suite with the JIT enabled, and compare the wall-clock time to CPython 3.14 without the JIT. Do not rely on micro-benchmarks. Run your actual application under realistic load. A 10 percent improvement on a synthetic benchmark means nothing if your real bottleneck is database queries or network I/O. If your application spends 95 percent of its time waiting for PostgreSQL and 5 percent executing Python, a 10 percent Python speedup yields a 0.5 percent overall improvement. Know where your time actually goes before you get excited about interpreter optimizations.

If you use threading, free-threaded Python, or async-heavy workloads, the JIT does not help you today. Check back when the free-threading compatibility issue is resolved. This will likely require a PEP-level commitment and at least one more CPython release cycle. Realistically, do not budget engineering time around threaded JIT support before mid-2027.

If you need the absolute fastest Python runtime and are willing to deal with PyPy’s compatibility limitations, PyPy remains the better choice by a large margin. The performance gap has not meaningfully closed. Test your dependencies for PyPy compatibility — C extensions are the usual pain point — and if they pass, PyPy will give you a 50 to 90 percent speedup that CPython’s JIT cannot approach.

If your Python performance problems are in data processing rather than interpreter overhead, stop looking at JIT benchmarks and start looking at Polars, DuckDB, or NumPy 2.x. A 10 percent interpreter speedup does not compete with a 10x improvement from using a columnar engine. The biggest performance wins in Python in 2026 are not in the interpreter. They are in the libraries.

The Python Packaging Council, a new governance body that will oversee packaging interoperability standards, opens its inaugural election nominations on July 28. If you maintain Python packages or care about how packaging tools evolve, the PPC will make decisions that affect your workflow — including how pip, uv, Poetry, and other tools agree on lock file formats, dependency resolution, and build backends. Nominations are open to the community, and PSF Voting Members will elect the first council this year. If you have opinions about how Python packaging should work, this is the moment to get involved or at least pay attention ².

The JIT story is ultimately a story about Python growing up. The speedups are real but modest. The caveats are numerous but shrinking. The community debate about what the JIT should become is healthier than a premature commitment would have been. In mid-2026, the JIT is worth knowing about, worth testing with your code, and not yet worth restructuring your deployment around. That balance will shift. When it does, the PEP that formalizes the shift will be the signal. Until then, enable it if you can, measure it if you care, and spend your optimization budget on the libraries that give you 10x, not the interpreter that gives you 10 percent.

Footnotes

1. “Python’s JIT Faces Some Challenges and Other News for July 2026,” Real Python, July 6, 2026. https://realpython.com/python-news-july-2026 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸

2. “Get Ready: 2026 Python Packaging Council Nominations Opening Soon!,” Python Software Foundation Blog, July 23, 2026. https://blog.python.org/2026/07/2026-packaging-council-nominations ↩