Why does CPython 3.14's free-threaded build run single-threaded work slower than the default build?

## What the GIL was buying It is easy to describe the global interpreter lock only as a limitation: one thread executing bytecode at a time, so CPU-bound threads do not scale. The half that matters for this question is what it *bought*. Because only one thread ran interpreter code, an enormous amount of internal machinery could be written as if it were single-threaded: - **Reference counts** could be ordinary increments and decrements. No atomics, no memory fences, no cache-line ping-pong between cores. - **Built-in containers** needed no locks. Appending to a list or updating a dict was safe because nobody else was running. - **Interpreter-internal caches** — type version tags, method caches, the inline caches behind bytecode specialization — could be read and written without coordination. - **The allocator and the cycle collector** could assume exclusive access to their structures. Removing the GIL means paying, explicitly, for every one of those guarantees. ## What the free-threaded build has to do instead Reference counting is the big one, because it touches essentially every operation. Making counts atomic on every object would be ruinous, so the design mixes strategies: **immortal objects** whose counts are never touched at all (small ints, `None`, `True`, `False`, interned strings, type objects), **deferred reference counting** for objects the interpreter manipulates constantly, and biased or thread-local schemes so that the common case — an object touched only by the thread that created it — avoids contention. Objects genuinely shared between threads fall back to atomic operations, which are cheap in isolation and expensive when several cores fight over the same cache line. Mutable containers get **per-object locks**, so a list append is a lock acquisition rather than nothing. The allocator is restructured so lookups can proceed without taking a lock. The cycle collector needs a way to stop the world across real threads. Add it all up and a single-threaded program does strictly more work than it would under the GIL. That is the answer to the question in one sentence: **the free-threaded build has not removed work, it has moved the cost of thread safety from one big lock onto every object that needs protecting.** ## The numbers, and the version story The first free-threaded build shipped as an **experimental** option in **3.13**, and its single-threaded overhead was large — reported in the region of a third — largely because bytecode specialization had to be disabled in that build; the inline caches were not yet safe to mutate concurrently. In **3.14**, free-threading became **officially supported** (PEP 779) rather than experimental, and the overhead fell to roughly **5–10%**. A major part of that recovery was re-enabling the specializing adaptive interpreter in free-threaded builds, so hot code once again benefits from type-specialized instructions. The number is still a real cost, and it is still per release: quote it as "single digits to low double digits on 3.14" and say you would measure your own workload, not as a fixed constant. ## Everything else you pay Single-threaded slowdown is only the headline cost. **It is a separate build with a separate ABI.** You install a distinct interpreter, and every compiled extension in your dependency set must have been rebuilt for it. An extension that does not declare free-threading support causes the runtime to switch the GIL back on at import (with a warning) unless you explicitly override that — at which point you have a free-threaded build running with a GIL, paying the overhead and getting none of the benefit. **Thread-safety bugs that the GIL hid become real.** The GIL never made Python code race-free, but it made many races so unlikely they never fired. Removing it changes those odds. **Tooling lags.** Profilers, debuggers and native libraries need their own support. ## Making the call The deciding question is never "is the free-threaded build faster?" — it is "does this workload have parallel CPU-bound work in pure Python that the GIL is currently serialising?" Take a document-conversion queue as the concrete case. If its workers spend their time waiting on object storage and on an external converter process, the GIL is not the bottleneck: threads already overlap fine across blocking calls, and switching builds buys a slowdown and an ecosystem risk for nothing. If instead the conversion itself is pure-Python CPU work — parsing, transforming, laying out — running in many threads inside one process, then the GIL is exactly what is capping throughput, and the free-threaded build trades that 5–10% single-thread tax for scaling across cores. Weigh it against the alternative that needs no new build at all: separate processes, which cost memory and serialisation but keep every extension working. Whichever way you lean, decide it with a measurement of your own workload on both builds, at your real concurrency, over a long enough run to include steady-state behaviour — not with a benchmark someone published.