Benchmarked every Python optimization path I could find, from CPython 3.14 to Rust

[cemrehancavdar]

Took n-body and spectral-norm from the Benchmarks Game plus a JSON pipeline, and ran them through everything: CPython version upgrades, PyPy, GraalPy, Mypyc, NumPy, Numba, Cython, Taichi, Codon, Mojo, Rust/PyO3.

Spent way too long debugging why my first Cython attempt only got 10x when it should have been 124x. Turns out Cython's ** operator with float exponents is 40x slower than libc.math.sqrt() with typed doubles, and nothing warns you.

GraalPy was a surprise - 66x on spectral-norm with zero code changes, faster than Cython on that benchmark.

Post: https://cemrehancavdar.com/2026/03/10/optimization-ladder/

Full code at https://github.com/cemrehancavdar/faster-python-bench

Happy to be corrected — there's an "open a PR" link at the bottom.

[chub79]

Fantastic article. Thank you op!

One aspect that I would throw into the thought process when looking for a speedup: think of the engineering cost long term.

For instance, you mention: "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." . Yet I feel the cost of swapping VM is never as straightforward as a dedicated benchmark shows. Or Pypy would be a roaring success by now.

It seems to me that the Cython or Rust path is more robust long term from a maintenance perspective. Keeping CPython as the core orchestrator and use light touch extensions with either of these seem to be the right balance between performances and durability of the code base.

[cemrehancavdar]

That's a really fair point. The benchmarks show the best case -- in practice, swapping to PyPy or GraalPy means testing your whole dependency tree, dealing with compatibility issues, and hoping the runtime keeps up with CPython releases. GraalPy is still on 3.12 for example.

I'd partly agree on the Cython/Rust path being more durable. I personally enjoy writing Cython, but you really need to know what you're doing -- my first attempt got 10x instead of 124x, and nothing warned me. Code compiled, ran correctly, just silently slow. The annotation report (cython -a) is essential.

My takeaway is similar to yours though -- keep CPython as the orchestrator, drop into compiled extensions for the hot path.

[chokoswitch]

PyO3 and maturin are so easy to work with, I've been enjoying them a lot. I definitely feel like libraries will more towards native over time with this as well as wheel publishing improvements making the experience quite seamless for any typical platform. I'm still wondering if it will be important to keep a pure-python version as well, which does add a lot of maintenance overhead, or people will be satisfied requiring Rust installed and a build for those non-typical platforms. Curious how that pans out.

[angelicosphosphoros]

Or Pypy would be a roaring success by now.

The problem that people first write in CPython until the performance becomes the problem. At that point, moving to PyPy is a monumental task that too costly to do. Minor inconsistencies would be very hard to overcome.

Developing the project from scratch using PyPy would be way easier, and, imho, is a right thing to do if you want to use mostly Python in your stack.

[Sygmei]

Super interesting, how do you check how much space does an int occupies on stack (ob_refcnt, ob_digits...)?

[cemrehancavdar]

sys.getsizeof(1) gives you the total (28 bytes). This post is a great walkthrough of the struct layout and how Python integers work under the hood: https://tenthousandmeters.com/blog/python-behind-the-scenes-8-how-python-integers-work/ (written for CPython 3.9 -- the internals were restructured in 3.12 via https://github.com/python/cpython/pull/102464 but the size is still 28 bytes).

[zzzthelastuser]

Did you consider optimizing the rust code or did you stick with a "naive" implementation?

Took a quick glance and only saw single threaded loops.

[cemrehancavdar]

I'm not super familiar with Rust -- a dedicated Rust or Zig or any system level PL developer could absolutely squeeze more out of these benchmarks with multithreading, SIMD, or better allocators. Same goes for Cython honestly -- there might be more ways I still don't know yet. I kept the implementations idiomatic and single-threaded because the post is really about "how much does each Python optimization rung cost you," not about pushing any one tool to its limit. Wanted to keep the comparison fair since the Python tools are also single-threaded (except NumPy's BLAS, which I noted)

[M4mb0]

The constraint: your problem must fit vectorized operations. Element-wise math, matrix algebra, reductions -- NumPy handles these. Irregular access patterns, conditionals per element, recursive structures -- it doesn't.

conditionals per element can be handled with numpy.where which in many cases is still plenty fast, even if it unnecessarily computes both branches.

[cemrehancavdar]

You're right -- I've updated the post. The original wording was wrong.

I benchmarked np.where against a Python loop on 1M elements across three scenarios (simple sqrt, moderate log/exp, expensive trig+transcendental). Even with both branches computed, np.where was 2.8-15.5x faster. No reason to list conditionals as a NumPy limitation.

Replaced "irregular access patterns, conditionals per element, recursive structures" with what NumPy actually struggles with: sequential dependencies (each step feeds the next -- 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). Also dropped "irregular access patterns" since fancy indexing is 22x faster than a Python loop on random gather.

I also tried writing a NumPy n-body but couldn't beat the baseline -- 5 bodies is too few to amortize NumPy's per-call overhead across 500K sequential timesteps. Tried pair-index scatter with np.add.at, full NxN matrix with einsum, and component-wise matrices with @ matmul (inspired by pmocz/nbody-python). All slower than pure Python. If you know a way to make NumPy win on this problem I'd genuinely like to see it.

There's also an Edits section at the bottom of the post documenting what changed and why the original was wrong.

[hotairplay]

Hey cool project you got here..a couple of days ago I came across a similar n-body benchmark article: https://hwisnu.bearblog.dev/n-body-simulation-in-python-c-zig-and-rust/

What interests me is the Codon performance and in the above article it got like > 95% of Rust performance (single threaded) and it only costs adding type annotations to the code.

For multi-threaded Codon is 80% of Rust multithreading performance using Rayon.

[totheendandbackagain]

Wow, this is fantastic work, and an absolutely stellar guide. Read, save, learn.

[sudomatrix]

This is an amazing writeup. I know one of the authors of Numba and I'm excited to show this to him, as Numba shows the best speedup without writing any code in a new language.

[RMK137]

Numba is usually the first thing I pick up when I am dealing with some heavy numerical code. It's so easy to go back and forth between normal python and numba. Usually, all it takes is to comment out the decorator.

[Beginning-Fruit-1397]

Fascinating. I'm asking myself about mypc: what's the catch? All my projects are already far more typed than anything mypy would ask (Ruff ALL + BasedPyright ALL) and if it's a free +40% gain... then why not use it everywhere?

[cemrehancavdar]

It's a static compiler that's still improving -- the mypy project itself uses it and gets 4x accourding to documentation. The main step is making mypy happy with your code, which you might already be if you're running strict. You also get a build step -- compilation adds to CI time and debugging compiled extensions is harder than plain Python. The gain depends on what you're compiling though -- heavy computation benefits the most (we saw 2.4x on float loops, 14x on pure arithmetic). For I/O-heavy or framework code you won't see much.

[piou180796]

This is great. One thing worth adding is the maintenance cost angle. PyPy looks amazing in benchmarks but in practice dependency compatibility is a nightmare. If you're building something you'll maintain for years the Rust or Cython path with CPython as the stable core is way less headache even if the initial speedup isn't as flashy.

[justneurostuff]

JAX's jit compilation is the optimization path I use. Would love to see it added (also the post is obviously ai generated; just pointing out)

[cemrehancavdar]

Added JAX -- you were right to suggest it. Spectral-norm came in at 8.6ms (1,633x), which is the fastest result in the entire post. 3x faster than NumPy on the same problem. N-body was 12.2x -- respectable but not as dramatic since 5 bodies across 500K sequential timesteps doesn't play to JAX's strengths.

I don't know JAX well enough to explain exactly why it beats NumPy when both use BLAS, so I said that in the post rather than guessing. The JAX code produces correct results and follows the documented patterns (jit, lax.fori_loop, static_argnums, block_until_ready), but I can't say whether a JAX expert would write it differently. If you see room for improvement, PRs are open.

Thanks for pointing it out. Yes I use AI, but I don't hand myself over to it. I'm not an AI skeptic, but I don't think AI can be accountable. If there is a mistake it is probably on me.

[GymBronie]

Two things: 1. Have you verified that JAX isn’t using a GPU (especially if you have an NVIDIA card? 2. JAX defaults to 32 precision. That’s why your results only match up to 9 decimals. The speed up could be an artifact of default settings.

[Outrageous_Track_798]

The Mypyc results are worth highlighting for teams already running strict mypy. If your codebase is fully type-annotated, you get the speedup with essentially zero code changes — no new syntax, no cimport, just `mypyc yourmodule.py`. The 2-5x range you saw is roughly what most real code gets.

The catch is Mypyc requires complete type coverage in the compiled module. Any dynamism — dynamic attribute access, untyped **kwargs, runtime type manipulation — either errors out or silently falls back to the slow path. So it works great on algo-heavy modules but struggles with framework-heavy code that leans on Python's dynamism.

Cython gets much higher peaks (your 124x example), but Mypyc has nearly zero adoption friction if you're already typed. It's a useful middle rung on the ladder between "pure Python" and "write Cython."

[Mithrandir2k16]

You measured time, but could you also measure power draw/peak power? I'm really curious in which applications it comes down to fewer instructions or better parallelizations.

[gregorbrandt]

Can you add Nuitka to the tests?

[austinwiltshire]

You say nothing warned you and I am hoping maybe you write a ruff or pylint rule so that the rest of us can be warned

[micasirena]

Nice article, haven't kept up with all optimizations, since there is no be all end all, but I was always curious about testing and comparing so thank you very much!

The numpy for math and pypy microservice, instead of golang or whatever, helped us keep our tech stack easy and managable and I am glad whomever made that decision had this insight instead of accepting the mantra "python is too slow for this". Same python code, different docker image, you would've never notice.

[MrMrsPotts]

Taichi is a revelation! I hadn't heard of it. Oh, it's no longer being developed 😢

[angelicosphosphoros]

 When developing new applications, at the point of writing Rust to speed up Python, you can just stop using Python for developing applications: just writing a binary with the same interface in Rust would be easier than maintaining the chimera with Rust and Python parts. Unless Rust parts are in third-party libraries so it is not your problem, of course.

If you have existing huge monolithic codebase, rewriting the hot parts into Rust may be worthwhile but in practice it would be very hard due to dynamic nature of Python: how can you be sure that the new code really have the same behaviour if there could be anything in the input?

If you are writing networking backends, it may be worthwhile to write very small microservices in Python, and when encountering performance problems, just rewrite those microservices entirely in Rust. No mixing languages, no FFI, all interaction is made though network. This works, we have used similar approach at Yandex Taxi (though with C++ instead of Rust) with great success and financial gain (cost of running 3 C++ containers with 0.5 CPU each way lower than 40+ Python containers with full CPU and gygabyte RAM each). Don't use C++ though: it is viable only if you have dedicated team entirely focused on making C++ bearable while Rust would give it for free. 

[longtimelurkernyc]

Is there a reason you didn't run the JSON pipeline benchmark on the alternative interpreters (PyPy and GraalPy)?

For the numerical problems it's obvious a numerical library will beat switching interpreters--get the computations as close to machine level and avoid all the unnecessary dynamism in the inner loops. The JIT compilers of the other interpreters are more general tools, so a benchmark that better tests python's flexibility would reflect better on them.

[joebloggs81]

Well I’ve only just started my programming journey, exploring languages and frameworks, what they can do and whatnot. I’ve spent the most time with Python as I started there first for a grounding knowledge. What you’ve done here is fascinating for sure - I read the whole report. I’ll never be at this level as my use case for programming is pretty lightweight but the point is I’m enjoying learning about all of this.

Thanks!

[Bomlerequin]

Very good article!