Goal

Get RustPython interpreter performance close to (or beyond) CPython, while keeping the free-threading design: no GIL, and all chosen optimizations must remain sound under concurrent threads.

Measurement

• Machine: Apple M4, macOS (Darwin 25.2.0)
• RustPython: gc branch @ 2772a84e5, cargo build --release (thin LTO)
• CPython: 3.14.2 (Homebrew)
• Suite: ~140 small self-contained benchmark scripts (classic kernels: fannkuch, nbody, spectral_norm, fib variants + ~130 synthetic microbench scripts covering attribute access, calls, exceptions, comprehensions, unary/binary ops, etc.). Each script run 3 times per interpreter, best-of-3 wall clock, interpreter startup subtracted (startup itself is fine: 22.7ms vs 14.6ms).

Headline numbers

Across the 67 benchmarks where CPython execution takes >20ms:

• geometric mean: 5.4x slower than CPython, median 6.0x

Worst and best cases:

Micro-measurements (best-of-loop, per-operation cost):

Where the time goes (samply profiles)

Profiling the release binary over the benchmarks above consistently shows the same handful of structural costs; each has its own issue:

1. Per-instruction dispatch overhead — Opcode::cache_entries()/Opcode::deopt()/Instruction::as_opcode() chained match lookups + multiple atomic lasti updates per instruction consume 10–28% of total runtime depending on workload.
2. Python→Python call cost — per call: heap-allocated Frame PyObject (+GC tracking with a global lock), args Vec allocation, refcount churn, Rust-stack recursion.
3. LOAD_ATTR specialization is defeated for user-defined classes — their getattro slot is installed as getattro_wrapper, so the specializer bails and every attribute access goes through a full Python-level __getattribute__ call with MRO lookup + FuncArgs binding.
4. Even specialized attribute ops do full dict probes — LoadAttrWithHint doesn't use its hint; LoadAttrMethodWithValues does a whole dict lookup as its shadow check (no dict keys version).
5. Arithmetic allocates — every int/float result outside the −5..256 cache is a fresh heap object with a ~48-byte header; the specialized BinaryOpAddInt even takes the full BigInt path.
6. Allocation-time GC tracking + always-atomic refcounts — track_object takes a global generation-list RwLock + SeqCst atomics per tracked allocation; every incref/decref is an atomic RMW.
7. Build config — release profile leaves codegen-units at default and LTO at thin; low-hanging fruit.

Sub-issues:

• Perf: per-instruction dispatch overhead — metadata lookups and atomic lasti cost 10–28% of runtime #39 — per-instruction dispatch overhead (metadata lookups, atomic lasti, per-instruction checks)
• Perf: Python→Python call overhead is ~15x CPython (eager frame lifecycle + recursive eval loop) #40 — Python→Python call overhead (~15x)
• Perf: instance attribute access still ~7-11x slower than CPython (specialized LOAD_ATTR does a full dict lookup) #41 — LOAD_ATTR specialization defeated for user classes (getattro_wrapper)
• Perf: specialized LOAD_ATTR handlers still do full dict probes (hint unused, no keys-version shadow check) #42 — specialized LOAD_ATTR handlers still probe dicts
• Perf: small int/float arithmetic allocates heap objects; specialized BinaryOp*Int skips the i64 fast path #43 — small int/float allocation churn; BinaryOp*Int BigInt path
• Perf: GC tracking takes a global lock per allocation; refcounts always atomic — free-threading-friendly mitigations #44 — GC tracking global lock + always-atomic refcounts
• Perf: release build config — codegen-units, fat LTO, PGO #45 — release build config (codegen-units, LTO, PGO)
• Perf: specialized builtin/method-descriptor call opcodes still box arguments through Vec+FuncArgs and re-dispatch per call #47 — builtin/method-descriptor call opcodes box args through Vec+FuncArgs, re-dispatch per call
• Perf: hasattr/getattr miss builds and discards a full AttributeError — no suppressed-lookup path #48 — hasattr/getattr miss builds and discards a full AttributeError
• Perf: zip/enumerate/map allocate per item — no result-tuple reuse, RwLock<BigInt> counter, per-item args Vec #49 — zip/enumerate/map allocate per item (no result-tuple reuse)

What is already in good shape (verified during this analysis, no issue needed): adaptive specialization framework with CPython-compatible opcodes, inline caches with type/dict version tags, compact dict with interned-pointer fast path and cached string hashes, contiguous datastack for localsplus, LOAD_FAST_BORROW refcount elision, bigint arithmetic (faster than CPython).

This issue series was researched and written by Claude on behalf of @youknowone.