HN

Comments (45)

• Menu

  jakobnissen
  So not much progress since 3.14 - but still progress! Personally, I think it's nice when my code automatically gets faster thanks to someone else's work, and I don't understand all the negative sentiment in this thread. Yes, of course Python is still a slow language. You hopefully knew that when you picked Python for your project.
• scosman
  only tangentially related, but naming PyPy when PyPI was already established was ridiculous
• 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".
• Menu

  dezsiszabi
  Answer: not fast at all.
• Menu

  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
• Menu

  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 flowalso you could at least wrap the existing one in a `functools.cache`
• klooney
  I had kind of thought PyPy was dead, I'm glad to see they made it to 3.12
• perpetualpear
  The lazy imports are a reason to upgrade.
• Menu

  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.
• rurban
  2 benchmarks only? A very broad sense of coverage
• Menu

  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.
• anon
  undefined
• actionfromafar
  Not as fast as https://github.com/shedskin/shedskin
• luckydata
  not fast enough for me to care anymore