How Fast is Python 3.15?
Qem
55 points
37 comments
October 06, 2026
Related Discussions
Found 5 related stories in 104.7ms across 8,687 title embeddings via pgvector HNSW
- Libraries Run Rust Inside Python (With PyO3) lumpa · 62 pts · September 13, 2026 · 42% similar
- Python sets and dictionaries can have quadratic-time performance ibobev · 12 pts · September 08, 2026 · 42% similar
- 6× faster binary search: from compiled code to mechanical sympathy enz · 15 pts · July 12, 2026 · 41% similar
- EVE Online moves to Python 3 TylerJaacks · 29 pts · August 25, 2026 · 41% similar
- How did Apple Silicon get 50% faster in three years? – Daniel Lemire's blog ibobev · 18 pts · September 19, 2026 · 38% similar
Discussion Highlights (11 comments)
actionfromafar
Not as fast as https://github.com/shedskin/shedskin
makaimc
35 years on since the first public Python release and there's still so much room for improvement in its performance. These tests by Miguel are a useful quick check on that progress in 3.15 even if as he admits it's impossible to get "an objective and universal measure of the performance of a programming language".
brianwawok
So Claude can convert python code bases to rust or golang, and give you an easy 10x speed boost. Much better than waiting for Python performance to improve
rurban
2 benchmarks only? A very broad sense of coverage
bjourne
My pet peeve are numbers with too many decimals. If you only run a benchmark three times and take the arithmetic mean you don't have five or more significant digits. At best, you have two. And for benchmarking the geometric mean is a far superior mean.
DroneBetter
you should include a faster version of the fibonacci function with exponentiation by squaring def fibonacci(k): a,b=(0,1) for i in range(k.bit_length()-1,-1,-1): d=a**2 c=2*a*b-d d+=b**2 (a,b)=(d,c+d) if k>>i&1 else (c,d) return a see https://oeis.org/wiki/User:Natalia_L._Skirrow/linear_recurre... (warning: old and bad and in need of revision), https://github.com/sympy/sympy/pull/30452 and https://github.com/sympy/sympy/pull/30541 for details of how to make similarly fast programs for arbitrary linear-recurrent sequences. you can also encode polynomials into integers; see https://mathstodon.xyz/@peterluschny/116320199782572958 and the following prog from https://codegolf.stackexchange.com/a/279771 lambda n:pow(p:=2<<n,n,p*p+~p)//p both of these would be more intensive on the arithmetic side rather than control flow also you could at least wrap the existing one in a `functools.cache`
scosman
only tangentially related, but naming PyPy when PyPI was already established was ridiculous
klooney
I had kind of thought PyPy was dead, I'm glad to see they made it to 3.12
luckydata
not fast enough for me to care anymore
sieve
I have been using Python for the past two years for various things. But it is criminally slow. I joke that using Python on your modern 2020s CPU upgrades it to a Pentium 4 from 2004 running code compiled with C. And the 2004 version might still be faster. Yes, some of the syntax is nice. But the rest of it, the scoping rules, the obstinacy around the lambda syntax, the venv/pip nonsense, path resolution etc is a hot mess. Were it not for astral tooling like uv, I would have abandoned it in a few weeks. I hate thinking about memory outside of very specific workflows, so I am willing to accept a 2-3x penalty over C for cleaner and shorter code that follows the happy path. But anything beyond that and you are wasting energy and people's time. For Python to work as something other than a glue language where we write all critical code in C/Rust and call it from inside Python, something like PyPy is almost mandatory. But the design of the language, the exposed innards, and the need to maintain backward compatibility makes optimization a chore. I did some benchmarking of Python against C, Go, Rust, Node, LuaJIT etc in preparation for my runtime.[1] My observations based on some stats: - You can blindly replace C with Rust for most tested workflows. There is very little performance difference outside of compiler speed. (C23 is a nice language though.) - Go is 2-3x slower than C - Node and LuaJIT are 3-8x slower on average compared to C - Python is 60-70x slower. It can get far, far slower in certain cases. You can run your own benchmarks. I think you might end up in the same ballpark. [1] I have been interested in reverse engineering, hobbyist compiler/VM development etc for a couple of decades and wondered what is the point of ranting for two years about it without doing anything concrete. So I decided to build a runtime and statically typed language borrowing stuff from Python and Erlang/BEAM. But, even with LLMs implementing my ideas faithfully, the last 20-30% is a never-ending process which means I get bored and move on to something I can finish in 3-4 days.
dezsiszabi
Answer: not fast at all.