Reading Grounds

Python JIT-Compiling

Take away point:

Python’s JIT is not a magic turbo button yet. It is a foundation for where CPython performance may go next.

Python has a speed problem.

That sentence alone can start an argument.

Some developers will say Python is fast enough because most real projects spend time waiting on databases, networks, files, APIs, or optimized libraries like NumPy. Others will point out that pure Python loops can still feel slow compared with Java, JavaScript, C#, Go, Rust, or C++.

Then there is the bigger controversy: if JavaScript, Java, .NET, Julia, Ruby, and even PyPy can use JIT compilation, why has standard Python taken so long to experiment with it directly?

That is where CPython’s experimental JIT becomes interesting. Python 3.13 added an experimental JIT option when CPython is configured and built with --enable-experimental-jit, and the official documentation says it may speed up some Python programs.^[1]

It is not a magic speed button. It is not yet something most developers should expect to turn on in production and immediately see huge performance gains. But it does show that the default Python implementation is exploring a very important performance direction.

To understand why that matters, we first need to understand how traditional CPython runs code.

Traditional CPython: Code, Bytecode, Interpreter

Most people say Python is an interpreted language.

That is mostly true, but there is an important middle step.

Traditional CPython does not simply read your .py file and execute the text directly. First, it compiles Python source code into bytecode. Then the CPython interpreter executes that bytecode.

A simple way to picture it is:

Traditional CPython: Python code → bytecode → interpreter executes bytecode

For example, when you write:

x = 10 
y = 20 
print(x + y)

CPython turns that code into lower-level bytecode instructions. The interpreter then runs those instructions.

This model is one reason Python is flexible and portable. But it also helps explain why pure Python code can be slower than code from languages that compile more aggressively into machine code.

Experimental JIT CPython: Compiling Hot Code at Runtime

A JIT compiler, or Just-In-Time compiler, compiles some code while the program is running.

Instead of only interpreting bytecode instruction by instruction, a JIT watches for parts of the program that run repeatedly. Those frequently used sections are often called “hot code.”

The goal is to compile some of that hot code into faster machine-level instructions.

A simple way to picture experimental JIT CPython is:

Experimental JIT CPython: Python code → bytecode → some hot code may be compiled at runtime

That distinction is key.

The experimental JIT does not mean Python stops using bytecode. It does not mean every line of Python suddenly becomes compiled like C or Rust. It means CPython is experimenting with a path where some frequently executed code can be compiled while the program runs.^[1]

That is a major shift in direction.

What Does JIT Mean?

JIT stands for Just-In-Time.

There are three broad ways to think about language execution:

Interpreter: Reads and runs code step by step. Ahead-of-time compiler: Compiles code before the program runs. JIT compiler: Compiles parts of the program while the program is running.

Languages like C and Rust are usually ahead-of-time compiled. The program is compiled before it runs.

Traditional CPython is usually described as interpreted, although it does compile Python code into bytecode first.

A JIT sits somewhere in the middle. It allows the runtime to learn from the program while it is running. If a certain function or loop is used many times, the JIT may optimize that part.

This is powerful because the runtime can make decisions based on real behavior, not just static source code.

Java: One of the Classic JIT Success Stories

Java is one of the most famous examples of successful JIT compilation.

Java source code is compiled into bytecode. That bytecode runs on the Java Virtual Machine, or JVM. While the program runs, the JVM watches what code is used heavily. Hot code can then be compiled into optimized machine code.

The flow looks like this:

Java code → bytecode → JVM → hot code becomes optimized machine code

This is one reason Java can perform very well in long-running applications. A Java program may need some warm-up time, but after the JVM has observed enough runtime behavior, it can optimize important parts of the program.

This is a useful comparison for Python because CPython also uses bytecode. The difference is that CPython historically did not have a major built-in JIT like the JVM.

JavaScript: JIT Helped Transform the Web

JavaScript is another major JIT story.

Modern JavaScript engines, such as V8, SpiderMonkey, and JavaScriptCore, use advanced JIT techniques. This helped JavaScript move from simple browser scripting to full-scale application development.

Today, JavaScript powers complex web apps, browser games, server-side applications, desktop apps, and development tools.

That transformation would be much harder without modern JavaScript engine optimization.

JavaScript is also dynamic, like Python. A variable can hold different kinds of values, and objects can change shape at runtime.

For example:

function add(a, b) { return a + b; }

If a JavaScript engine notices that a and b are usually numbers, it may optimize that function for numeric addition.

But if the code later does this:

add("hello", "world")

the engine may need to fall back to a more general path.

That is one of the big challenges with JIT compilation in dynamic languages. The runtime can make smart guesses, but those guesses must remain safe. If reality changes, the runtime may need to de-optimize.

.NET and C#: JIT as a Normal Runtime Feature

In .NET, JIT compilation is a normal part of the runtime model.

C# code is usually compiled into intermediate language code. Then the .NET runtime compiles that intermediate code into machine code for the current system.^[5]

The basic model is:

C# code → intermediate language → .NET runtime JIT → machine code

So in .NET, JIT is not experimental in the same way CPython’s JIT is experimental. It is part of the normal execution strategy.

That comparison makes Python’s situation clearer. JIT itself is not a strange or unproven idea. What is experimental is CPython’s specific attempt to add JIT machinery into the default Python implementation.

Julia: JIT for High-Performance Computing

Julia is another useful comparison.

Julia was designed for high-performance scientific and numerical computing. It feels interactive and dynamic, but it uses JIT compilation through LLVM.

That is one reason Julia can perform extremely well on certain numeric workloads.

However, Julia also shows one of the tradeoffs of JIT compilation: startup and first-run delay. A program may take time to compile important pieces before reaching its fastest performance.

This is sometimes discussed as the “time to first plot” problem in Julia.

So JIT can improve performance, but it is not free. It may add complexity, memory use, warm-up time, and new kinds of performance surprises.

PyPy: Python Already Had a JIT

This is a crucial point: Python-the-language has already had JIT implementations.

The best-known example is PyPy.

PyPy is an alternative Python implementation with a JIT compiler. PyPy’s own project site describes speed as one of its advantages and specifically credits its Just-in-Time compiler for often making Python programs run faster on PyPy.^[3]

But PyPy is not the default Python implementation most people use. Most developers use CPython, the reference implementation of Python.

So CPython’s experimental JIT is not “the first Python JIT ever.”

A more accurate statement is:

Python has had JIT implementations before. CPython is now experimenting with JIT support directly.

That distinction matters.

When people say “Python is getting a JIT,” they usually mean CPython is experimenting with JIT compilation. They do not mean no Python implementation has ever had a JIT before.

Ruby and YJIT: Another Dynamic Language Comparison

Ruby is also dynamic like Python, and modern Ruby has invested in JIT work too, especially YJIT.

Ruby’s experience matters because it shows that dynamic languages can benefit from JIT compilation, but it also shows that the work is difficult. Ruby’s documentation describes YJIT as a lightweight Ruby JIT built inside CRuby that lazily compiles code using Basic Block Versioning.^[4]

Dynamic languages are flexible. That flexibility is a feature, but it creates optimization problems.

A JIT must ask questions like:

Can I assume this value is always an integer? Can I assume this method still means the same thing? Can I assume this object layout will stay stable? Can I optimize this without changing language behavior?

If those assumptions stop being true, the JIT needs a safe fallback.

Python has similar challenges.

Why Python’s JIT Is Hard

Python is extremely dynamic.

A variable can point to an integer, then a string, then a list:

x = 10 
x = "hello" 
x = [1, 2, 3]

Python also supports dynamic imports, decorators, monkey patching, custom attribute access, metaclasses, and many other flexible behaviors.

That flexibility is one of Python’s strengths. It is also one of the reasons optimization is hard.

A JIT compiler wants stable patterns. Python often allows patterns to change at runtime.

The JIT has to be careful. It cannot simply assume Python behaves like a static language. It must preserve Python’s normal behavior.

That is one reason CPython’s JIT work should be understood as a long-term engineering effort, not a quick trick.

Python’s Experimental JIT Results So Far

The current results are mixed.

That is exactly why the feature is still experimental.

In Python 3.13, CPython added an experimental JIT option when Python is built with the right configuration. The documentation says it may speed up some Python programs. That wording is careful. It does not promise that all programs will become faster.^[1]

Python 3.14 continues the JIT story, but the current picture is still uneven.

Some reports and discussions around Python 3.14 describe potential performance changes in a range roughly from slower to faster depending on workload. A practical way to explain the current state is:

Some workloads: faster Some workloads: little difference Some workloads: slower Production use: not the main recommendation yet

PEP 744 describes the CPython JIT as an experimental addition and explains that the PEP is meant to summarize its design decisions, current implementation status, and future plans for potentially making the JIT a permanent, non-experimental part of CPython.^[2]

That point is important.

The experimental JIT is not yet the kind of feature where every Python program suddenly becomes much faster. It is better understood as performance infrastructure.

In article-friendly terms:

The JIT is exciting because it shows where CPython may be going. It is controversial because turning it on does not guarantee your code will go faster today.

Why the Results Are Uneven

JIT performance depends heavily on the workload.

A program with repeated hot loops may be a better candidate for JIT improvements than a short script that mostly waits on a network request.

A long-running application may have more opportunity to benefit from runtime optimization than a tiny command-line script that starts, does one thing, and exits.

The JIT also has overhead. The runtime has to detect hot code, compile code, manage assumptions, and preserve correct behavior. If the cost of that machinery is greater than the benefit, the program may not speed up.

This is why JITs often shine in certain workloads but disappoint in others.

That is not unique to Python. Java, JavaScript, .NET, Julia, Ruby, and PyPy all involve tradeoffs around warm-up, optimization, de-optimization, memory use, and runtime complexity.

The Real Controversy

The CPython JIT debate is not only about speed.

It is about Python’s future.

Python has traditionally won because it is simple, readable, flexible, and supported by a massive ecosystem. But performance pressure keeps increasing.

Developers want Python to remain easy, but they also want it to compete better for modern workloads.

That creates hard questions:

Can CPython become faster without becoming more complex for users? Will the JIT help normal Python code or only special cases? Will the JIT increase memory use or startup cost? Will it work well with Python’s huge package ecosystem? Will it reduce the need for alternative Python runtimes?

These are not small questions.

The JIT is exciting because it suggests CPython is willing to evolve. It is controversial because Python developers have seen many performance promises before, and real-world results are rarely simple.

JIT Is Proven. CPython’s JIT Is Experimental.

This is the fairest summary:

JIT compilation is a proven idea. CPython’s JIT is the experimental part.

Java has shown that JIT can make bytecode-based runtimes very fast.

JavaScript has shown that JIT can make dynamic languages powerful enough for huge applications.

.NET has shown that JIT can be a normal part of mainstream application development.^[5]

Julia has shown that JIT can support high-performance technical computing.

PyPy has shown that Python code can benefit from JIT techniques.^[3]

Ruby’s YJIT has shown that dynamic language runtimes are still actively exploring JIT optimization.^[4]

So Python is not entering unknown territory because JIT is unproven. Python is entering difficult territory because CPython must support Python’s flexibility, compatibility, C extension ecosystem, and user expectations.

That is a much harder problem than simply saying “add a JIT.”

Final Takeaway

CPython’s experimental JIT is one of the most interesting Python performance stories because it changes the conversation around how Python might run in the future.

The key mental model is:

Traditional CPython: Python code → bytecode → interpreter executes bytecode Experimental JIT CPython: Python code → bytecode → some hot code may be compiled at runtime

That does not mean Python is suddenly as fast as Java, JavaScript, C#, Julia, or Rust.

It does not mean every Python program gets faster.

It does not mean the interpreter disappears.

It means CPython is experimenting with runtime compilation as part of its future performance strategy.

The practical conclusion is simple:

Python’s JIT is not a magic turbo button yet. It is a foundation for where CPython performance may go next.

And that is exactly why it matters.

Sources