The problem is that Python just isn't going to go fast. There are some languages that may have had more resources poured into them to make them go faster in absolute terms, like perhaps Java. But I don't think there's a single language that has had so many ways of trying to make it go faster given so much effort over so many decades. It's really time to call it... if you have Python code and it's a performance problem, if one of the many many many different solutions aren't adequate for some reason, Python is not going to get any faster than it is today and you're going to have to move off of it.
If you need high performance code, Python is simply not the right answer and you're going to have to skill up. Or accept what you have, which you'll have to decide if that's a viable option. If it's fast enough I don't advocate switching casually. But if it isn't, there isn't a realistic prospect that you're going to wake up in a year or two to a 30x-faster Python. I wasn't terribly convinced by that claim back in the early 2000s, but it hadn't really been tested yet. It has been tested now.
[–] anthk 2 days ago
[–] skeledrew 2 days ago
> RustPython is in development, and while the interpreter certainly can be used in interesting use cases like running Python in WASM and embedding into a Rust project, do note that RustPython is not totally production-ready.
[–] LtWorf 2 days ago
[–] jerf 1 day ago
Second, no, it isn't. Pypy is really fast compared to Python. "Compared to Python" is just about the lowest bar there is, though. In absolute terms it is still only a medium-fast language runtime, and it comes with a lot of costs and tradeoffs.
That's the problem with Python. Lots of ways to take a very slow language and make it a medium-fast language with substantial tradeoffs, or make it a fast language with enormous tradeoffs. If you can handle the tradeoffs, fine. But if you can't you just need to switch to a language that is fast without anywhere near as many tradeoffs.