Cemrehan Çavdar

The Optimization Ladder

Cemrehan Çavdar — Tue, 10 Mar 2026 20:00:00 +0000

Every year, someone posts a benchmark showing Python is 100x slower than C. The same argument plays out: one side says "benchmarks don't matter, real apps are I/O bound," the other says "just use a real language." Both are wrong.

I took two of the most-cited Benchmarks Game problems -- n-body and spectral-norm -- reproduced them on my machine, and ran every optimization tool I could find. Then I added a third benchmark -- a JSON event pipeline -- to test something closer to real-world code.

Same problems, same Apple M4 Pro, real numbers. This is one developer's journey up the ladder -- not a definitive ranking. A dedicated expert could squeeze more out of any of these tools. The full code is at faster-python-bench.

Here's the starting point -- CPython 3.13 on the official Benchmarks Game run:

Benchmark	C gcc	CPython 3.13	Ratio
n-body (50M)	2.1s	372s	177x
spectral-norm (5500)	0.4s	350s	875x
fannkuch-redux (12)	2.1s	311s	145x
mandelbrot (16000)	1.3s	183s	142x
binary-trees (21)	1.6s	33s	21x

The question isn't whether Python is slow at computation. It is. The question is how much effort each fix costs and how far it gets you. That's the ladder.

Why Python Is Slow

The usual suspects are the GIL, interpretation, and dynamic typing. All three matter, but none of them is the real story. The real story is that Python is designed to be maximally dynamic -- you can monkey-patch methods at runtime, replace builtins, change a class's inheritance chain while instances exist -- and that design makes it fundamentally hard to optimize.

A C compiler sees a + b between two integers and emits one CPU instruction. The Python VM sees a + b and has to ask: what is a? What is b? Does a.__add__ exist? Has it been replaced since the last call? Is a actually a subclass of int that overrides __add__? Every operation goes through this dispatch because the language guarantees you can change anything at any time.

The object overhead is where this shows up concretely. In C, an integer is 4 bytes on the stack. In Python:

C int:        [    4 bytes    ]

Python int:   [ ob_refcnt  8B ]    reference count
              [ ob_type    8B ]    pointer to type object
              [ ob_size    8B ]    number of digits
              [ ob_digit   4B ]    the actual value
              ─────────────────
              = 28 bytes minimum

(Simplified -- CPython 3.12+ replaced ob_size with lv_tag in a restructured int layout. Total is still 28 bytes. See longintrepr.h.)

4 bytes of number, 24 bytes of machinery to support dynamism. a + b means: dereference two heap pointers, look up type slots, dispatch to int.__add__, allocate a new PyObject for the result (unless it hits the small-integer cache), update reference counts. CPython 3.11+ mitigates this with adaptive specialization -- hot bytecodes like BINARY_OP_ADD_INT skip the dispatch for known types -- but the overhead is still there for the general case. One number isn't slow. Millions in a loop are.

The GIL (Global Interpreter Lock) gets blamed a lot, but it has no impact on single-threaded performance -- it only matters when multiple CPU-bound threads compete for the interpreter. For the benchmarks in this post, the GIL is irrelevant. CPython 3.13 shipped experimental free-threaded mode (--disable-gil) -- still experimental in 3.14 -- but as we'll see, it actually makes single-threaded code slower because removing the GIL adds overhead to every reference count operation.

The interpretation overhead is real but is being actively addressed. CPython 3.11's Faster CPython project added adaptive specialization -- the VM detects "hot" bytecodes and replaces them with type-specialized versions, skipping some of the dispatch. It helped (~1.4x). CPython 3.13 went further with an experimental copy-and-patch JIT compiler -- a lightweight JIT that stitches together pre-compiled machine code templates instead of generating code from scratch. It's not a full optimizing JIT like V8's TurboFan or a tracing JIT like PyPy's; it's designed to be small and fast to start, avoiding the heavyweight JIT startup cost that has historically kept CPython from going this route. Early results in 3.13 show no improvement on most benchmarks, but the infrastructure is now in place for more aggressive optimizations in future releases. JavaScript's V8 achieves much better JIT results, but V8 also had a large dedicated team and a single-threaded JavaScript execution model that makes speculative optimization easier. (For more on the "why doesn't CPython JIT" question, see Anthony Shaw's "Why is Python so slow?".)

So the picture is: Python is slow because its dynamic design requires runtime dispatch on every operation. The GIL, the interpreter, the object model -- these are all consequences of that design choice. Each rung of the ladder removes some of this dispatch. The higher you climb, the more you bypass -- and the more effort it costs.

Rung 0: Upgrade CPython

Cost: changing your base image. Reward: up to 1.4x.

Version	N-body	vs 3.14	Spectral-norm	vs 3.14
CPython 3.10	1,663ms	0.75x	16,826ms	0.83x
CPython 3.11	1,200ms	1.04x	13,430ms	1.05x
CPython 3.13	1,134ms	1.10x	13,637ms	1.03x
CPython 3.14	1,242ms	1.0x	14,046ms	1.0x
CPython 3.14t (free-threaded)	1,513ms	0.82x	14,551ms	0.97x

The story is 3.10 to 3.11: a 1.39x speedup on n-body, for free. That's the Faster CPython project -- adaptive specialization of bytecodes, inline caching, zero-cost exceptions. 3.13 squeezed out a bit more. 3.14 gave some of it back -- a minor regression on these benchmarks.

Free-threaded Python (3.14t) is slower on single-threaded code. The GIL removal adds overhead to every reference count operation. Worth it only if you have genuinely parallel CPU-bound threads. (Full version comparison)

This rung costs nothing. If you're still on 3.10, upgrade.

Rung 1: Alternative Runtimes (PyPy, GraalPy)

Cost: switching interpreters. Reward: 6-66x.

	N-body	Spectral-norm
CPython 3.14	1,242ms	14,046ms
GraalPy	211ms (5.9x)	212ms (66x)
PyPy	98ms (13x)	1,065ms (13x)

Both are JIT-compiled runtimes that generate native machine code from your unmodified Python. Zero code changes. Just a different interpreter.

PyPy uses a tracing JIT -- it records hot loops and compiles them. GraalPy runs on GraalVM's Truffle framework with a method-based JIT. PyPy wins on n-body (13x vs 5.9x), but GraalPy dominates spectral-norm (66x vs 13x) -- the matrix-heavy inner loop plays to GraalVM's strengths. GraalPy also offers Java interop and is actively developed by Oracle.

The catch: ecosystem compatibility. Both support major packages, but C extensions run through compatibility layers that can be slower than on CPython. GraalPy is on Python 3.12 (no 3.14 yet) and has slow startup -- it's JVM-based, so the JIT needs warmup before reaching peak performance. For pure Python code with long-running hot loops -- these are free speed.

Rung 2: Mypyc

Cost: type annotations you probably already have. Reward: 2.4-14x.

	N-body	Spectral-norm
CPython 3.14	1,242ms	14,046ms
Mypyc	518ms (2.4x)	990ms (14x)

Mypyc compiles type-annotated Python to C extensions using the same type analysis as mypy. No new syntax, no new language -- just your existing typed Python, compiled ahead of time.

# Already valid typed Python -- mypyc compiles this to C
def advance(dt: float, n: int, bodies: list[Body], pairs: list[BodyPair]) -> None:
    dx: float
    dy: float
    dz: float
    dist_sq: float
    dist: float
    mag: float
    for _ in range(n):
        for (r1, v1, m1), (r2, v2, m2) in pairs:
            dx = r1[0] - r2[0]
            dy = r1[1] - r2[1]
            dz = r1[2] - r2[2]
            dist_sq = dx * dx + dy * dy + dz * dz
            dist = math.sqrt(dist_sq)
            mag = dt / (dist_sq * dist)
            # ...

The difference from the baseline: explicit type declarations on every local variable so mypyc can use C primitives instead of Python objects, and decomposing ** (-1.5) into sqrt() + arithmetic to avoid slow power dispatch. That's it -- no special decorators, no new build system beyond mypycify().

The mypy project itself -- ~100k+ lines of Python -- achieved a 4x end-to-end speedup by compiling with mypyc. The official docs say "1.5x to 5x" for existing annotated code, "5x to 10x" for code tuned for compilation. The spectral-norm result (14x) lands above that range because the inner loop is pure arithmetic that mypyc compiles directly to C. On our dict-heavy JSON pipeline, mypyc hit 2.3x on pre-parsed dicts -- closer to the expected floor.

The constraint: mypyc supports a subset of Python. Dynamic patterns like **kwargs, getattr tricks, and heavily duck-typed code will compile but won't be optimized -- they fall back to slow generic paths. But if your code already passes mypy strict mode, mypyc is the lowest-effort compilation rung on the ladder.

Rung 3: NumPy

Cost: knowing NumPy. Reward: up to 520x.

	Spectral-norm
CPython 3.14	14,046ms
NumPy	27ms (520x)

520x. Faster than our single-threaded Rust at 154x on the same problem -- though NumPy delegates to BLAS, which uses multiple cores.

Spectral-norm is matrix-vector multiplication. NumPy pre-computes the matrix once and delegates to BLAS (Apple Accelerate on macOS):

a = build_matrix(n)
for _ in range(10):
    v = a.T @ (a @ u)
    u = a.T @ (a @ v)

Each @ is a single call to hand-optimized BLAS with SIMD and multithreading. NumPy trades O(N) memory for O(N^2) memory -- it stores the full 2000x2000 matrix (30MB) -- but the computation is done in compiled C/C++ (Apple Accelerate on macOS, OpenBLAS or MKL on Linux), not Python.

This is the lesson people miss when they say "Python is slow." Python the loop runner is slow. Python the orchestrator of compiled libraries is as fast as anything.

The constraint: your problem must fit vectorized operations. Element-wise math, matrix algebra, reductions, conditionals (np.where computes both branches and masks the result -- redundant work, but still faster than a Python loop on large arrays) -- NumPy handles all of these. What it can't help with: sequential dependencies where each step feeds the next, recursive structures, and small arrays where NumPy's per-call overhead costs more than the computation itself.

Interlude: JAX

Cost: rewriting loops as jax.lax.fori_loop + array operations. Reward: 12-1,633x.

A Reddit commenter (justneurostuff) suggested testing JAX -- an array computing library that uses XLA JIT compilation. I expected it to land somewhere near NumPy. I was wrong.

	N-body	Spectral-norm
CPython 3.14	1,242ms	14,046ms
NumPy	--	27ms (520x)
JAX JIT	100ms (12.2x)	8.6ms (1,633x)

8.6ms on spectral-norm. That's 3x faster than NumPy and the fastest result in this entire post. On n-body, 12.2x -- between Mypyc and Numba. Both results match the CPython baseline to 9 decimal places. This is single-threaded -- forcing one thread gave 9.1ms vs 8.6ms on spectral-norm.

I don't know JAX well enough to explain exactly why it's 3x faster than NumPy on the same matrix multiplications. Both call BLAS under the hood. My best guess is that JAX's @jit compiles the entire function -- matrix build, loop, dot products -- so Python is never involved between operations, while NumPy returns to Python between each @ call. But I haven't verified that in detail. Might be time to learn.

The catch: JAX is a different programming model. Python loops become lax.fori_loop. Conditionals become lax.cond. You're writing functional array programs that happen to use Python syntax -- closer to a domain-specific language than a drop-in optimizer. But if your problem fits, the numbers speak for themselves. JAX isn't the only library that compiles array code -- PyTorch has torch.compile, for example. I only tested JAX, so I can't say whether others would produce similar results on these benchmarks.

Rung 4: Numba

Cost: @njit + restructuring data into NumPy arrays. Reward: 56-135x.

	N-body	Spectral-norm
CPython 3.14	1,242ms	14,046ms
Numba @njit	22ms (56x)	104ms (135x)

Numba JIT-compiles decorated functions to machine code via LLVM:

@njit(cache=True)
def advance(dt, n, pos, vel, mass):
    for i in range(n):
        for j in range(i + 1, n):
            dx = pos[i, 0] - pos[j, 0]
            dy = pos[i, 1] - pos[j, 1]
            dz = pos[i, 2] - pos[j, 2]
            dist = sqrt(dx * dx + dy * dy + dz * dz)
            mag = dt / (dist * dist * dist)
            vel[i, 0] -= dx * mag * mass[j]
            # ...

One decorator. Restructure data into NumPy arrays. The constraint: Numba works best with NumPy arrays and numeric types. It has limited support for typed dicts, typed lists, and @jitclass, but strings and general Python objects are largely out of reach. It's a scalpel, not a saw.

Rung 5: Cython

Cost: learning C's mental model, expressed in Python syntax. Reward: 99-124x.

	N-body	Spectral-norm
CPython 3.14	1,242ms	14,046ms
Cython	10ms (124x)	142ms (99x)

124x on n-body. Within 10% of Rust. But here's the thing about this rung:

My first Cython n-body got 10.5x. Same Cython, same compiler. The final version got 124x. The difference was three landmines, none of which produced warnings:

Cython's ** operator with float exponents. Even with typed doubles and -ffast-math, x ** 0.5 is 40x slower than sqrt(x) in Cython -- the operator goes through a slow dispatch path instead of compiling to C's sqrt(). The n-body baseline uses ** (-1.5), which can't be replaced with a single sqrt() call -- it required decomposing the formula into sqrt() + arithmetic. 7x penalty on the overall benchmark.
Precomputed pair index arrays prevent the C compiler from unrolling the nested loop. 2x penalty. The "clever" version is slower.
Missing @cython.cdivision(True) inserts a zero-division check before every floating-point divide in the inner loop. Millions of branches that are never taken.

Cython's promise is that it "makes writing C extensions for Python as easy as Python itself." In practice that means: learn C's mental model, express it in Python syntax, and use the annotation report (cython -a) to verify the compiler did what you think. The full story is in The Cython Minefield.

The reward is real -- 99-124x, matching compiled languages. But the failure mode is silent. All three landmines cost you silently, and the annotation report is the only way to catch them.

Rung 6: The New Wave

Cost: new toolchains, rough edges, ecosystem gaps. Reward: 26-198x.

Three tools promise to compile Python (or Python-like code) to native machine code. I tested all three.

	N-body	Speedup	Spectral-norm	Speedup	The catch
Codon 0.19	47ms	26x	99ms	142x	Own runtime, limited stdlib, limited CPython interop
Mojo nightly	11ms	113x	118ms	119x	New language (pre-1.0), full rewrite required
Taichi 1.7	16ms	78x	71ms	198x	Python 3.13 only (no 3.14 wheels)

The numbers are real. The developer experience is rough. Codon can't import your existing code. Mojo is a new language wearing Python's clothes -- but with SIMD vectorization and compile-time loop unrolling, it reaches Rust/Cython territory on n-body (113x). Taichi has the best spectral-norm result (198x) but doesn't ship wheels for Python 3.14 -- its numbers above were benchmarked on a separate Python 3.13 environment. That's the compromise with these tools: if your runtime doesn't keep up with CPython releases, you're stuck on an old version or juggling multiple environments. (Full deep dive with code and DX verdicts)

None are drop-in. All are worth watching.

Rung 7: Rust via PyO3

Cost: learning Rust. Reward: 113-154x.

	N-body	Spectral-norm
CPython 3.14	1,242ms	14,046ms
Rust (PyO3)	11ms (113x)	91ms (154x)

The top of the ladder. But notice: on n-body, Cython at 10ms, Mojo at 11ms, Rust at 11ms -- they're essentially tied. All compiled to native machine code. The remaining difference is noise, not a fundamental language gap.

The real Rust advantage isn't raw speed -- it's pipeline ownership. When Rust parses JSON directly with serde into typed structs, it never creates a Python dict. It bypasses the Python object system entirely. That matters more on the next benchmark.

The Ceiling

The Benchmarks Game problems are pure compute: tight loops, no I/O, no data structures beyond arrays. Most Python code looks nothing like that. So I built a third benchmark: load 100K JSON events, filter, transform, aggregate per user. Dicts, strings, datetime parsing -- the kind of code that makes Numba useless and makes Cython fight the Python object system.

First, every tool starts from pre-parsed Python dicts -- same input, same work:

Approach	Time	Speedup	What it costs you
CPython 3.14	48ms	1.0x	Nothing
Mypyc	21ms	2.3x	Type annotations
Cython (dict optimized)	12ms	4.1x	Days of annotation work

4.1x. Not 50x. The bottleneck is Python dict access. Even Cython's fully optimized version -- @cython.cclass, C arrays for counters, direct CPython C-API calls (PyList_GET_ITEM, PyDict_GetItem with borrowed refs) -- still reads input dicts through the Python C API.

But wait -- why are we feeding Cython Python dicts at all? json.loads() takes ~57ms to create those dicts. That's more than the entire baseline pipeline. What if Cython reads the raw bytes itself?

I wrote a second Cython pipeline that calls yyjson -- a general-purpose C JSON parser, comparable to Rust's serde_json. Both are schema-agnostic: they parse any valid JSON, not just our event format. Cython walks the parsed tree with C pointers, filters and aggregates into C structs, and builds Python dicts only for the final output. For Rust, idiomatic serde with zero-copy deserialization. Both own the data end-to-end:

Approach	Time	Speedup	What it costs you
CPython 3.14 (json.loads + pipeline)	105ms	1.0x	Nothing
Mypyc (json.loads + pipeline)	77ms	1.4x	Type annotations
Cython (json.loads + pipeline)	67ms	1.6x	C-API dict access
Rust (serde, from bytes)	21ms	5.0x	New language + bindings
Cython (yyjson, from bytes)	17ms	6.3x	C library + Cython declarations

6.3x for Cython, 5.0x for Rust. The ceiling was never the pipeline code -- it was json.loads(). Both approaches use general-purpose JSON parsers -- yyjson on the Cython side, serde on the Rust side -- and both avoid Python objects entirely in the hot loop: Cython walks yyjson's C tree into C structs, Rust deserializes into native structs via serde.

I'm not claiming Cython is faster than Rust or vice versa. A sufficiently motivated person could make either one faster -- swap parsers, tune allocators, restructure the pipeline. The point isn't which tool wins this specific benchmark. The point is how many rungs you're willing to climb. Both land in the same neighborhood once you bypass json.loads(). The code is at faster-python-bench.

The Full Report Card

N-body (500K iterations, tight floating-point loops)

Approach	Time	Speedup	What it costs you
CPython 3.10	1,663ms	0.75x	Old version
CPython 3.14	1,242ms	1.0x	Nothing
CPython 3.14t	1,513ms	0.82x	GIL-free but slower single-thread
Mypyc	518ms	2.4x	Type annotations
GraalPy	211ms	5.9x	Python 3.12 only, ecosystem compatibility
JAX JIT	100ms	12.2x	Rewrite loops as `lax.fori_loop`
PyPy	98ms	13x	Ecosystem compatibility
Codon	47ms	26x	Separate runtime, limited stdlib
Numba	22ms	56x	`@njit` + NumPy arrays
Taichi	16ms	78x	Python 3.13 only (no 3.14 wheels)
Mojo	11ms	113x	New language + toolchain
Cython	10ms	124x	C knowledge + landmines
Rust (PyO3)	11ms	113x	Learning Rust

Spectral-norm (N=2000, matrix-vector multiply)

Approach	Time	Speedup	What it costs you
CPython 3.10	16,826ms	0.83x	Old version
CPython 3.14	14,046ms	1.0x	Nothing
CPython 3.14t	14,551ms	0.97x	GIL-free but slower single-thread
Mypyc	990ms	14x	Type annotations
GraalPy	212ms	66x	Python 3.12 only, ecosystem compatibility
PyPy	1,065ms	13x	Ecosystem compatibility
Codon	99ms	142x	Separate runtime, limited stdlib
Numba	104ms	135x	`@njit` + NumPy arrays
Mojo	118ms	119x	New language + toolchain
Rust (PyO3)	91ms	154x	Learning Rust
Cython	142ms	99x	C knowledge + landmines
Taichi	71ms	198x	Python 3.13 only (no 3.14 wheels)
NumPy	27ms	520x	Knowing NumPy + O(N^2) memory
JAX JIT	8.6ms	1,633x	Rewrite loops as `lax.fori_loop`

JSON pipeline (100K events, end-to-end from raw bytes)

Approach	Time	Speedup	What it costs you
CPython 3.14 (json.loads + pipeline)	105ms	1.0x	Nothing
Mypyc (json.loads + pipeline)	77ms	1.4x	Type annotations
Cython (json.loads + pipeline)	67ms	1.6x	C-API dict access
Rust (serde, from bytes)	21ms	5.0x	New language + bindings
Cython (yyjson, from bytes)	17ms	6.3x	C library + Cython declarations

When to Stop Climbing

The effort curve is exponential. Mypyc (2.4-14x) costs type annotations. PyPy/GraalPy (6-66x) costs a binary swap. Numba (56-135x) costs a decorator and data restructuring. JAX (12-1,633x) costs rewriting your code functionally. Cython (99-124x) costs days and C knowledge. Rust (113-154x) costs learning a new language.

Upgrade first. 3.10 to 3.11 gives you 1.4x for free.

Mypyc for typed codebases. If your code already passes mypy strict, compile it. 2.4x on n-body, 14x on spectral-norm, for almost no work.

NumPy for vectorizable math. If your problem is matrix algebra or element-wise operations, NumPy gets you 520x with code you already know.

JAX if you can express it functionally. Same array paradigm as NumPy, but XLA whole-graph compilation took spectral-norm to 1,633x -- 3x faster than NumPy. The cost is rewriting loops as lax.fori_loop and conditionals as lax.cond. On problems that don't vectorize well (n-body with 5 bodies), JAX is 12x -- good but not exceptional.

Numba for numeric loops. @njit gives you 56-135x with one decorator and honest error messages.

Cython if you know C. 99-124x is real, but the failure mode is silent slowness.

Rust for pipeline ownership. On pure compute, Cython and Rust are neck and neck. The real advantage is when Rust owns the data flow end-to-end.

PyPy or GraalPy for pure Python. 6-66x for zero code changes is remarkable, if your dependencies support it. GraalPy's spectral-norm result (66x) rivals compiled solutions.

Most code doesn't need any of this. The pipeline benchmark -- the most realistic of the three -- topped out at 4.1x when starting from Python dicts. 6.3x when Cython called yyjson and owned the bytes. If your hot path is dict[str, Any], the answer might be "stop creating dicts," not "change the language." And if your code is I/O bound, none of this matters at all.

Profile before you optimize. cProfile to find the function. line_profiler to find the line. Then pick the right rung.

Not covered: Nuitka (Python-to-C compiler, mostly used for packaging -- speedups are in the Mypyc range), Pythran (NumPy-focused AOT compiler, niche), SPy (Antonio Cuni's static Python dialect -- not ready yet but worth watching), and CinderX (Meta's performance-oriented CPython fork -- not ready yet).

Found an error? Open a PR.

Edits

2026-03-10: Rewrote the NumPy constraints paragraph. The original listed "irregular access patterns, conditionals per element, recursive structures" as things NumPy can't handle. Two of those were wrong: NumPy fancy indexing handles irregular access fine (22x faster than Python on random gather), and np.where handles conditionals (2.8-15.5x faster on 1M elements, even though it computes both branches). Replaced with things NumPy actually can't help with: sequential dependencies (n-body with 5 bodies is 2.3x slower with NumPy), recursive structures, and small arrays (NumPy loses below ~50 elements due to per-call overhead).

2026-03-10: The original text said "Early results are modest (single-digit percent improvements)" -- implying the 3.13 JIT was already delivering gains. Changed to "Early results in 3.13 show no improvement on most benchmarks." Bad wording on my part -- 3.13 JIT shows no speedup (and can be slightly slower). The speedups are coming in 3.15: Savannah Ostrowski's preliminary FastAPI benchmarks show ~8% improvement on 3.15 (see also doesjitgobrrr.com). Thanks to Fidget-Spinner (CPython core developer working on the JIT) for the correction.

2026-03-11: Added JAX JIT benchmarks after a Reddit comment from justneurostuff suggested testing it. Results: 1,633x on spectral-norm (fastest in the post -- 3x faster than NumPy), 12.2x on n-body. Both match baseline to 9 decimal places. Added as an interlude between NumPy and Numba sections, and to both report card tables.

2026-03-19: Updated Mojo n-body result from 16ms (78x) to 11ms (113x) after PR #2 by jgsimard applied SIMD vectorization and compile-time loop unrolling. Mojo now ties Rust/Cython on n-body.

pip install ziglang

Cemrehan Çavdar — Thu, 05 Mar 2026 20:00:00 +0000

I built marimo-cython, Cython inside marimo notebooks. A few days later, Vincent Warmerdam (one of my favorite YouTubers, he runs calmcode) opened a PR to add a "Open in molab" badge. molab is marimo's cloud notebook platform.

Then he closed his own PR:

Ah wait, nevermind, it seems we don't have gcc on molab containers by default.

Right. Cython compiles Python to C, then you need a C compiler to turn that C into a .so file. No gcc, no Cython. The whole point of marimo-cython (write Cython in a notebook and run it) doesn't work if the environment can't compile C.

The idea

Zig is a systems programming language, but the important part for this story is that it ships with a full C/C++ compiler toolchain built on Clang/LLVM. And the ziglang PyPI package bundles the entire Zig binary distribution.

uv add ziglang
uv run python-zig cc --version
# clang version 20.1.2

A C compiler. As a Python dependency. Installed with uv add. Lives in the venv. No system packages, no Xcode, no apt install build-essential.

So the plan was simple: add ziglang as a dependency, set CC="python-zig cc", and the molab notebook compiles Cython extensions without gcc. Should take about 20 minutes.

Fixing the lightbulb

There's a scene in Malcolm in the Middle where Hal goes to fix a lightbulb, but the shelf is in the way, so he has to fix the shelf, but the screw is stripped, so he needs to get a new one, but the drawer is broken, and so on, each fix revealing the next problem. That's what happened.

Step 1: just use zig cc directly

CC="python-zig cc" uv run python setup.py build_ext --inplace

Crash. On macOS, Python's build system passes -bundle to the linker. zig cc silently ignores it and produces an executable instead of a shared library. It also passes -LModules/_hacl, a relative path baked into sysconfig from CPython's own build. Apple's clang ignores the missing directory. zig cc does not. And -Wl,-headerpad,0x40 crashes the zig 0.15.x linker outright.

OK, so raw zig cc doesn't work. Surely someone's solved this.

Step 2: find zigcc on PyPI

There's a package called zigcc, a wrapper that filters out problematic flags. Exactly what I need.

Except it's archived. And it has a bug: it drops any argument containing the substring -x. On Linux x86_64, the output path often includes linux-x86_64, which matches. So zigcc drops the output file argument and the build silently produces nothing.

OK, I'll write my own.

Step 3: write a wrapper, fix macOS

Started with the -bundle problem: rewrite it to -shared, same output format Python expects. Build runs further. Now -LModules/_hacl crashes it, drop it. Now -Wl,-headerpad,0x40 crashes it.

Is -headerpad safe to drop? I built the same extension with Apple ld (which honors the flag) and with zig ld (which doesn't). Compared the Mach-O headers with otool -l:

# Apple ld
sizeofcmds 1576

# zig ld
sizeofcmds 1576

Identical. The flag does nothing in practice for Python extensions. Drop it.

macOS works.

Step 4: try Linux, try OpenMP

Linux had its own set of flags (-Wl,--exclude-libs, -Wl,-Bsymbolic-functions) none of which zig's linker supports. More drops, more checking whether the drops are safe. They are, for normal extension builds. Linux works too.

I packaged the whole thing as zig-cc-python.

Then I tried OpenMP. Worked on Linux. On macOS, prange loops silently returned wrong results. zig cc compiled the code without actually emitting the parallel runtime calls. No fix. Moved on.

The payoff

Eight flags. The entire wrapper is ~80 lines of Python. That's what took days. It's harder when you're not sure you know what you're doing.

The PR that started this works now. Here's a marimo notebook compiling Cython on molab, no gcc, no system compiler, just Python packages.

What I learned

A C compiler is a huge piece of machinery. Swapping one in isn't like swapping a JSON library. The build system, the platform linker, and decades of accumulated flags all assume a specific compiler. I got basic Cython extensions working, but that's a narrow slice. I couldn't get OpenMP to work on macOS. I haven't tested C++ heavily, or cross-compilation, or extensions that link against system libraries in unusual ways. There are probably flags I haven't hit yet.

The wrapper is on PyPI and on GitHub. Some findings and a thin wrapper to save the next person from the same debugging. If you hit something it doesn't handle, open an issue.

Oh, and while I was deep in linker flags and otool output, Vincent asked the marimo engineers to just add gcc to the molab containers. The original notebook already works now.

I know what this looks like.

Your Framework Doesn't Matter

Cemrehan Çavdar — Thu, 19 Feb 2026 20:00:00 +0000

Last week I benchmarked four web frameworks and found that BlackSheep is 2x faster than FastAPI. A Rust-based server and JSON serializer pushed Python within striking distance of Go. Impressive numbers.

But I kept thinking: does any of this matter? Those benchmarks measured localhost throughput with no database and no network. That's not what users experience. A real API request crosses the internet, hits a framework, queries a database through an ORM, serializes the result, and travels back. How much of that time is actually the framework?

So I built a real app, deployed it, and measured every phase.

The App

A book catalog API. FastAPI + SQLAlchemy 2.0 (async) + asyncpg + Uvicorn. The standard Python stack that a developer following the FastAPI docs would use. No exotic dependencies, no optimization tricks.

Three tables: Publisher -> Author -> Book. Seeded with 4,215 real books from the Open Library API: Agatha Christie, Dostoevsky, Penguin Books, real data with real-world cardinality.

Deployed to Fly.io on a shared-cpu-1x machine with 512MB RAM and Postgres 17, both in Amsterdam. The cheapest setup you'd use for a side project.

Four endpoints:

GET /api/health returns {"status": "ok"}. No database, no ORM, no serialization. Pure framework overhead.
GET /api/books/{id} single book with author details. 4 SQL queries via selectinload.
GET /api/books?page=1&per_page=100 100 books with full details. 5 queries, selectinload.
GET /api/books/n-plus-one?page=1&per_page=100 same data as #3, but with the classic N+1 bug. 302 queries (2 + 100 x 3 individual SELECTs).

Endpoint #4 is the "what not to do" scenario. Same response, same data, but instead of letting SQLAlchemy batch the loads, each book triggers separate queries for its author, publisher, and sibling books.

How I Measured

Every response carries timing headers measured with time.perf_counter(). The database layer uses SQLAlchemy's before_cursor_execute / after_cursor_execute events to split ORM overhead from raw driver time. A contextvars.ContextVar stores per-request timings so nothing leaks between concurrent requests.

The client measures total round-trip time. Network = client total - server total.

I ran 200 requests per endpoint from Turkey to Amsterdam (~57ms baseline RTT), with 30 warmup requests discarded. All numbers below are medians.

Where Does Server Time Go?

Let's start with what happens inside the server. No network, just the work Python does.

DB Driver ORM Serialize Encode Framework

Health check (no DB, no work) 0.3ms server, 0 queries

0.04ms 0.25ms

Single book + author 11.5ms server, 4 queries

6.0ms 4.6ms

100 books, optimized 30.2ms server, 5 queries

10.6ms 14.2ms 3.1ms

100 books, N+1 queries 491.9ms server, 302 queries

330.4ms 152.1ms

Hover over any segment for percentages. Bars don't sum to exactly 100%. A small residual (1-3%) falls between the timed sections.

The health check tells the story immediately. When there's no database, the framework is the server, 82% of 0.3ms. But the moment you add real work, it disappears. For the optimized 100-book query, the DB driver and ORM together account for 82% of server time. Serialization is 10%. The framework (FastAPI's routing, middleware, dependency injection) is 2-3%. For the single book endpoint, it's 4%.

The N+1 scenario is brutal. Same data, same response, but 302 queries instead of 5. Server time goes from 30ms to 492ms, a 16x increase, because each of those 302 queries pays a round-trip to Postgres and an ORM hydration cost.

But this is still only the server's perspective. What does the user actually experience?

Now Zoom Out

Same four endpoints, but now we include what happens before and after the server: DNS, TCP, TLS, request travel, response travel, all lumped together as "Network."

Pick a distance to see how it changes the picture:

Network DB Driver ORM Serialize Encode Framework

Health check (no DB, no work) 69.6ms total

69.2ms

Single book + author 68.8ms total

56.9ms 6.0ms 4.6ms

100 books, optimized 97.0ms total

66.6ms 10.6ms 14.2ms 3.1ms

100 books, N+1 queries 613.2ms total

82.2ms 330.4ms 152.1ms

Framework is 0.2–0.9% of total response time

Hover over any segment for percentages. Server timings are constant, only network changes.

There it is. The health check, where the framework has nothing to do except route and respond, is 99% network. The server finishes in 0.3ms. The user waits 70ms.

For a single book lookup, 83% of what the user waits for is the network. The entire server (framework, ORM, database, serialization, JSON encoding) is the remaining 17%. The framework specifically is 0.7%.

For 100 books with proper queries, network is 69%. The server does more work (30ms vs 12ms), but the user still spends most of their time waiting for packets to cross the internet.

These numbers default to my setup. I live in Ankara, Turkey, and my closest Fly.io region is Amsterdam. Try the presets above to see how distance changes the picture. Even in the best case (same building, 5ms) network is still 30% of a single book lookup. And most SaaS products aren't running multi-region deployments with edge nodes. They have one server in one region.

The N+1 scenario flips everything. Network drops to 13%, not because the network got faster, but because the server got so slow (492ms) that it dwarfs the network time. This is the only scenario where server-side code meaningfully impacts user experience. And the cause isn't the framework, it's 302 queries instead of 5.

Framework Overhead Across All Scenarios

Scenario	Total	Framework	Framework %
Health check (no DB)	69.6ms	0.2ms	0.4%
Single book	68.8ms	0.5ms	0.7%
100 books (optimized)	97.0ms	0.7ms	0.8%
100 books (N+1)	613.2ms	1.3ms	0.2%

The health check is the best case for the framework: no database, no ORM, no serialization. The server does almost nothing. And still, framework overhead is 0.2ms out of a 70ms request. FastAPI's routing, middleware, dependency injection, and ASGI handling cost 0.2-1.3ms across all scenarios. That's the thing benchmarks compare when they say "FastAPI vs BlackSheep" or "Python vs Go." The thing that accounts for less than 1% of what users experience.

In my previous benchmark, BlackSheep was 2x faster than FastAPI. That 2x difference applies to 0.7% of the total response time. Switching frameworks would save roughly 0.25ms on a 69ms request.

Putting Traffic in Perspective

Let's say your API gets 1 million requests per day. That sounds like a lot. It's 12 requests per second.

Daily Requests	Avg req/s	Peak req/s (3x avg)
100,000	1.2	3.5
1,000,000	11.6	35
10,000,000	115.7	347

Levels.fyi, a site with 1-2 million monthly uniques and over $1M ARR, runs one of its most trafficked services on a single Node.js instance serving 60K requests per hour. That's 17 req/s. FastAPI handles 46,000 req/s on a single worker in my benchmarks. You have roughly 2,700x headroom.

In 2016, Stack Overflow served 209 million HTTP requests per day (about 2,400 req/s average) on 9 web servers. Nick Craver said they'd unintentionally tested running on a single server, and it worked.

Framework throughput differences don't matter when your actual traffic is three orders of magnitude below capacity.

What I Didn't Measure

This is a sequential measurement from a single client, no concurrent load. Under concurrency, connection pooling, async scheduling, and GIL contention could change the server-side breakdown. The "Framework" bucket lumps together Uvicorn, Starlette, and FastAPI. I didn't separate them. "Network" lumps DNS, TLS, TCP, and raw packet travel. Response sizes are pre-compression (the real responses would be smaller over gzip).

At scale, a faster framework means fewer servers, that's real cost savings. But "at scale" means hundreds of thousands of requests per second, not millions per day. And long before you get there, you'll have optimized your queries, added caching, moved to handwritten SQL, and maybe even forked your runtime. Facebook built their own Python before they worried about framework overhead.

All measurements: 200 samples each, medians, from Turkey to Amsterdam. The raw data is in the repository.

What I Learned

Deploy closer to your users. For well-written queries, 69-83% of response time is packets crossing the internet. No framework optimization changes this. If your server is in Amsterdam and your users are in Ankara, they're waiting 57ms before your code even runs. Move the server, or put a cache at the edge.

Fix your queries, not your framework. The N+1 bug turned a 97ms response into a 613ms one, 6.3x slower, and framework overhead was still only 0.2%. Switching from FastAPI to BlackSheep would save 0.25ms. Fixing the N+1 bug saves 516ms. Profile your queries. Add selectinload. Use EXPLAIN ANALYZE. That's where the seconds are.

Pick your framework for everything except speed. Framework benchmarks compare the one component that doesn't matter (0.2-0.8% of total time) under conditions that don't exist (localhost, no database, no network). Pick for developer experience, documentation, ecosystem, and hiring. The framework that lets you ship faster is the fast framework.

If you want to see what actually makes a website fast in practice, Wes Bos has a great breakdown. Hint: it's not the framework.

Benchmarking is hard. I'm sure I got something wrong, missed an important variable, or made an assumption that doesn't hold. All the code, measurement scripts, and raw timing data are in the repository. Please try to break it. If you find a flaw in the methodology, a timing error, or a scenario that would change the conclusions, I genuinely want to hear about it.

Benchmarking Gin, Elysia, BlackSheep, and FastAPI

Cemrehan Çavdar — Tue, 10 Feb 2026 20:00:00 +0000

I always felt like JavaScript and Go are the alternative languages for Python. I wouldn't compare Python to Rust or Zig. So when I keep seeing Gin vs Elysia benchmarks, I wanted to throw Python into the mix. FastAPI says it's fast right in the name. Let's find out.

Four frameworks, three languages, same Docker constraints, same endpoints.

Source code on GitHub

TLDR: Python's ecosystem (Granian, orjson) makes it fast enough to beat Bun's Elysia on validation and routing. Gin (Go) still wins overall. BlackSheep > FastAPI by 2x. Full numbers and code below.

The Setup

Every framework runs in a Docker container with identical constraints:

Server: 2 CPUs, 512MB RAM, 2 workers
Client: wrk with 2 threads, 128 connections, 10 seconds per endpoint
Machine: Apple M4 Pro
Four endpoints: plaintext, JSON, URL params, POST validation

The "2 workers" part is important. Go uses GOMAXPROCS=2, Python uses 2 uvicorn workers, and Bun uses cluster mode with 2 processes. Everyone gets two CPU cores and two parallel execution contexts.

Each endpoint does progressively more work:

/plaintext return "Hello, World!" (raw I/O)
/json return {"message": "Hello, World!"} (serialization)
/user/42 parse a URL param, return {"id": "42", "name": "User 42"} (routing)
POST /validate parse JSON body, validate fields, return result (real-world work)

The Contenders

FastAPI (Python)

from fastapi import FastAPI
from fastapi.responses import PlainTextResponse
from pydantic import BaseModel, Field

app = FastAPI()

HELLO = "Hello, World!"


class UserInput(BaseModel):
    name: str = Field(min_length=1)
    age: int = Field(ge=0, le=150)


@app.get("/plaintext")
async def plaintext() -> PlainTextResponse:
    return PlainTextResponse(HELLO)


@app.get("/json")
async def json_endpoint() -> dict:
    return {"message": HELLO}


@app.get("/user/{user_id}")
async def get_user(user_id: str) -> dict:
    return {"id": user_id, "name": f"User {user_id}"}


@app.post("/validate")
async def validate(body: UserInput) -> dict:
    return {"name": body.name, "age": body.age, "valid": True}

The crowd favorite. Pydantic models give you validation, serialization, and OpenAPI docs in one shot. It's the most productive framework here, but that productivity has a cost at runtime, which we'll see in the numbers.

Gin (Go)

package main

import (
	"fmt"
	"net/http"
	"os"
	"runtime"
	"strconv"

	"github.com/gin-gonic/gin"
)

const hello = "Hello, World!"

type ValidateInput struct {
	Name string `json:"name" binding:"required,min=1"`
	Age  int    `json:"age" binding:"required,gte=0,lte=150"`
}

func main() {
	workers := 4
	if v, err := strconv.Atoi(os.Getenv("WORKERS")); err == nil && v > 0 {
		workers = v
	}
	runtime.GOMAXPROCS(workers)

	gin.SetMode(gin.ReleaseMode)
	r := gin.New()

	r.GET("/plaintext", func(c *gin.Context) {
		c.String(http.StatusOK, hello)
	})

	r.GET("/json", func(c *gin.Context) {
		c.JSON(http.StatusOK, gin.H{"message": hello})
	})

	r.GET("/user/:id", func(c *gin.Context) {
		id := c.Param("id")
		c.JSON(http.StatusOK, gin.H{
			"id":   id,
			"name": fmt.Sprintf("User %s", id),
		})
	})

	r.POST("/validate", func(c *gin.Context) {
		var input ValidateInput
		if err := c.ShouldBindJSON(&input); err != nil {
			c.JSON(http.StatusBadRequest, gin.H{"error": err.Error()})
			return
		}
		c.JSON(http.StatusOK, gin.H{
			"name":  input.Name,
			"age":   input.Age,
			"valid": true,
		})
	})

	r.Run(":3000")
}

Gin is terse. Struct tags handle validation. The gin.H{} shorthand for map literals keeps handlers compact. Go's goroutine scheduler makes concurrency almost invisible. You just set GOMAXPROCS and everything scales.

Elysia (Bun)

import { Elysia, t } from "elysia";

const HELLO = "Hello, World!";
const PORT = 3000;

new Elysia()
  .get("/plaintext", () => HELLO)
  .get("/json", () => ({ message: HELLO }))
  .get("/user/:id", ({ params }) => ({
    id: params.id,
    name: `User ${params.id}`,
  }))
  .post(
    "/validate",
    ({ body }) => ({
      name: body.name,
      age: body.age,
      valid: true,
    }),
    {
      body: t.Object({
        name: t.String({ minLength: 1 }),
        age: t.Integer({ minimum: 0, maximum: 150 }),
      }),
    }
  )
  .listen(PORT);

The most elegant of the bunch. Elysia's API is beautifully minimal. Return an object and it becomes JSON. The TypeBox schema validation (t.Object, t.String) is declarative and type-safe. Bun's runtime makes it fast.

BlackSheep (Python)

from blacksheep import Application, Request
from blacksheep.server.responses import json as json_resp
from blacksheep.server.responses import text as text_resp

app = Application()

HELLO = "Hello, World!"


@app.router.get("/plaintext")
async def plaintext():
    return text_resp(HELLO)


@app.router.get("/json")
async def json_endpoint():
    return json_resp({"message": HELLO})


@app.router.get("/user/{user_id}")
async def get_user(user_id: str):
    return json_resp({"id": user_id, "name": f"User {user_id}"})


@app.router.post("/validate")
async def validate(request: Request):
    body = await request.json()
    name = body.get("name")
    age = body.get("age")

    if not isinstance(name, str) or not name:
        return json_resp({"error": "name must be a non-empty string"}, status=400)
    if not isinstance(age, int) or age < 0 or age > 150:
        return json_resp(
            {"error": "age must be an integer between 0 and 150"}, status=400
        )

    return json_resp({"name": name, "age": age, "valid": True})

Most Python developers haven't heard of BlackSheep. No magic, no heavy abstractions, manual validation. You'll see why it's here in a moment.

Results

All numbers are requests per second, higher is better. Each framework ran with 2 workers on 2 CPUs.

Framework	Plaintext	JSON	Params	Validate (POST)
Gin (Go)	299,632	288,408	266,471	195,275
Elysia (Bun)	246,068	219,089	185,984	102,488
BlackSheep (Python)	152,005	129,958	128,939	98,829
FastAPI (Python)	79,785	66,114	51,560	45,963

A few things jump out.

Gin wins everything, which isn't surprising. Go's goroutine scheduler and compiled performance are hard to beat. But it's not a blowout against Elysia on plaintext (300k vs 246k, only 22% ahead).

Elysia drops hard under load. From plaintext (246k) to validate (102k), it loses 58% of its throughput. Bun is fast at raw I/O, but TypeBox validation in JavaScript is expensive relative to the baseline.

BlackSheep is shockingly fast for Python. 152k req/s on plaintext, and it holds up well under load, only a 35% drop to validate (99k). That validate number is close to Elysia's (102k vs 99k). A Python framework running at 96% of Bun's speed on a real workload.

FastAPI is about half of BlackSheep across the board. The Pydantic validation layer and middleware stack cost roughly 2x in overhead. Still, 46k req/s on validate is respectable.

So Can BlackSheep Get Even Faster?

Two swaps. Granian instead of uvicorn, a Rust-based ASGI server. orjson instead of stdlib json, a Rust-based JSON serializer. Same application code, different plumbing:

import orjson
from blacksheep import Application, Content, Request, Response
from blacksheep.server.responses import text as text_resp

app = Application(show_error_details=False)

HELLO = "Hello, World!"
CT_JSON = b"application/json"


def json_bytes_response(data: dict, status: int = 200) -> Response:
    """Build a Response from orjson-serialized bytes."""
    return Response(status, content=Content(CT_JSON, orjson.dumps(data)))


@app.router.get("/plaintext")
async def plaintext():
    return text_resp(HELLO)


@app.router.get("/json")
async def json_endpoint() -> Response:
    return json_bytes_response({"message": HELLO})


@app.router.get("/user/{user_id}")
async def get_user(user_id: str) -> Response:
    return json_bytes_response({"id": user_id, "name": f"User {user_id}"})


@app.router.post("/validate")
async def validate(request: Request) -> Response:
    body = orjson.loads(await request.read())
    name = body.get("name")
    age = body.get("age")

    if not isinstance(name, str) or not name:
        return json_bytes_response({"error": "name must be a non-empty string"}, 400)
    if not isinstance(age, int) or age < 0 or age > 150:
        return json_bytes_response(
            {"error": "age must be an integer between 0 and 150"}, 400
        )

    return json_bytes_response({"name": name, "age": age, "valid": True})

Framework	Plaintext	JSON	Params	Validate (POST)
Gin (Go)	299,632	288,408	266,471	195,275
Elysia (Bun)	246,068	219,089	185,984	102,488
BlackSheep+Granian+orjson	204,575	202,394	189,881	119,527
BlackSheep (uvicorn)	152,005	129,958	128,939	98,829
FastAPI (Python)	79,785	66,114	51,560	45,963

Yes it can. BlackSheep+Granian+orjson beats Elysia on validate (120k vs 102k) and params (190k vs 186k). The JSON endpoint improved 56%. That's what swapping json.dumps() for a Rust serializer does.

What I Learned

Python may be slower, but the ecosystem makes it fast. The language itself isn't winning any speed contests. But Granian (Rust HTTP server), orjson (Rust JSON), and uvloop (Cython event loop) let Python compete with Bun and get within striking distance of Go. The ecosystem does the heavy lifting.

The server matters as much as the framework. Swapping uvicorn for Granian gave a 35% boost on plaintext without changing application code. HTTP parsing and connection management aren't free.

Validation is the great equalizer. Raw I/O benchmarks favor compiled languages. But once every framework has to parse JSON, validate fields, and return structured errors, the gaps shrink. BlackSheep goes from 62% of Gin on plaintext to 61% on validate. Elysia goes from 82% to 52%.

All the code, Dockerfiles, and raw results are in the repository. Benchmarking is hard. If you spot something unfair or wrong, please tell me.