How does CPython's specializing adaptive interpreter (PEP 659) speed up hot code?

## The cost the interpreter used to pay every time CPython executes bytecode: a loop fetches an instruction, dispatches to the code implementing it, runs it, and moves on. Before 3.11, an instruction such as the one behind `a + b` was fully general on every execution. It had to look at the left operand's type, find that type's addition slot, decide whether the right operand's type deserved a chance to handle the operation instead, handle the possibility of subclasses, and only then do the arithmetic. For two small integers the bookkeeping dwarfed the addition itself. Real programs, though, are boringly stable *per location*. A line that adds two integers the first time overwhelmingly adds two integers the millionth time. A method call site usually calls the same function. An attribute access usually touches the same class's ordinary instance layout. PEP 659, shipped in **3.11**, turns that observation into speed. ## Quickening The bytecode stored in a `.pyc` is immutable and shared. So when a code object starts being executed repeatedly, CPython *quickens* it: it operates on a private, writable copy of the instruction stream. In that copy, general instructions are replaced by **adaptive** variants whose job is to watch what actually passes through them and then to rewrite themselves. Each general instruction heads a **family** of specialized forms. Binary operations have members for two ints, two floats, two strings; attribute loads have members for an attribute stored in the ordinary instance layout, one for a slot, one for a class attribute; calls have members for a plain Python function whose arguments match exactly, for a bound method, for common C functions. The adaptive form counts executions, observes the operand shapes and, once it is confident, overwrites itself in place with the family member that fits. ## Inline caches and guards Specialization would be pointless if the fast path still had to re-derive its facts. So each specialized instruction is followed, *inside the instruction stream*, by **inline cache** entries — code units reserved for exactly this — holding whatever the fast path needs: a type's version tag, an attribute's offset in the instance layout, a resolved function pointer. Reading them is a memory access rather than a lookup chain. This is why a code object's bytecode got larger in 3.11: the caches live inline, adjacent to the instruction that uses them. Every specialized instruction opens with a **guard**: a cheap check that the recorded assumption still holds — is this operand still exactly an int, does this object's type still carry the version the cache captured? Pass, and the tight path runs. Fail, and the instruction **deoptimizes**: it falls back to the general implementation, computes the correct result (semantics never change), and updates its counters. A site that keeps missing backs off exponentially before attempting to specialize again, so a genuinely polymorphic site does not thrash between forms forever. ## What it is not Nothing here emits machine code. This is still interpretation — just interpretation with far less per-instruction overhead — and it is not a tracing JIT compiling whole loops. It needs no flag, no build option and no source change, which makes it the honest answer to "why did our service get faster when we upgraded the interpreter?". CPython's later experimental JIT (added in **3.13**, still experimental and off by default in **3.14**) sits *on top* of this tier, consuming what the specializing machinery has already learned. Specialization is also per instruction, not per function. Two call sites in one function can settle on different specializations, and a third can remain general because its inputs genuinely vary. ## Seeing it happen A disassembly shows the pristine instructions the compiler produced. Asking for the adaptive view instead shows the current, quickened state, so running a function in a loop and then disassembling adaptively reveals the specialized names that replaced the general ones. ## What it means for the code you write **Type stability is now a performance property.** A helper handed ints on some calls and strings on others makes its arithmetic and attribute sites polymorphic; keeping payload shapes uniform, or splitting the helper, lets each site settle on one form. **Benchmarks must warm up.** Timing a single cold call measures the unspecialized path. Repetition-based timing naturally warms the code; a hand-rolled one-shot stopwatch does not, and will report a number that no longer describes the steady state. **Dynamic tricks have a price.** Classes mutated at run time, or objects that intercept attribute lookup dynamically, invalidate recorded type versions and force repeated deoptimization. **The wins are broad but modest per site.** Specialization removes overhead; it does not change an algorithm's complexity. It is the reason an upgrade is worth taking, not a substitute for fixing an O(n²) loop.