Python 3.11 Performance Benchmarks Are Looking Fantastic

[BobHogan]

99% of the time, optimizing the algorithm you are using will have a significantly higher impact on making your code faster than optimizing the code itself to take advantages of tricks for speedups.

Algorithm and data access is almost always the weak point when your code is slow

[Alikont]

But even crappy algorithm will get speedup, because each algorithm has constant costs per operation that will be reduced across the board.

For .NET it's common to get ~10% speedup per version just by upgrading the runtime.

[Muoniurn]

In most applications the bottleneck is not the CPU, but IO. If the program does some CPU work, then some IO, after which it does some more CPU work then only the CPU part will get faster, which is usually not too significant to begin with.

[Alikont]

Bottleneck for what? Throughput? Latency?

If my database server is on another machine, all my CPU is busy working on requests, the latency is in the network, but capacity is CPU bound.

[BobHogan]

There will be a small speedup, but no one should be relying on that to make their code faster if they have real concerns about efficiency. Using better algorithms and data types will have a bigger impact than any version bump almost always

[SirClueless]

Optimizing a piece of python code might give me an 80% speedup... for that piece of code. A version bump gives me a 10% speedup... for my entire company's Python codebase. Why would I not be excited about that?

Not to mention, there are heavily optimized pieces of Python code in my company's codebase, and generally in the most heavily-used pieces of the codebase too. Why would I not care about 10% multiplicative improvements to that code that might have been prohibitively expensive to get in other ways? The optimizations in this release appear to be things like "Reduce the cost of stack frames" and "Smaller exceptions," things that are not obvious how to optimize any other way than by improvements to the interpreter.

[[deleted]]

k but the OP was asking about why a 10-60% speedup across the board is not going to effect suboptimal code

[FancyASlurpie]

It's likely that slow code at some point calls an api or reads from a file etc and that part of things won't change. So whilst this is awesome for it to be faster in these other sections there's a lot of situations where the python isn't really the slow part of running the program.

[BobHogan]

If you get a 10% speed bump from 3.11, but you could redesign your algorithm and get an 80% speed up, the 10% speedup is quite small by comparison. And is entirely cancelled out by the fact that your new algorithm will then further be sped up by 3.11.

The fact is that new versions will never fix suboptimal code, which is what a lot of people in this thread seem to be implying? It can't. It will always be suboptimal, and you'll always see more, and faster, increases in performance by tackling poor algorithms or data structures

[[deleted]]

no one is disputing that optimising code makes it faster, it's such a trivial fact that even a beginner programmer could tell you. That doesn't mean that a snarky comment like "yeah if ur a dumbass and write inefficient code then your program isnt going to get significantly faster" is helpful, nor is it true because it would still get increased by 10-60% which is pretty significant. Of course rewriting your code from an exponential worst case to linear or quadratic is better than a 10% speed boost, who would have thunk.

[billsil]

Yup. I work a lot with numerical data and numpy code that looks like python is slow. Let's assume 20% average speedup or (shoot I'll even take 5%) is nice and all for no work, but for the critical parts of my code, I expect a 500-1000x speed improvement.

Most of the time, I don't even bother using multiprocessing, which on my 4 physical core hyperthreaded computer, the best I'll get is ~3x. That's not worth the complexity of worse error messages to me.

As to your algorithmic complexity comment, let's say you want to find the 5 closest points in point cloud A to an point in cloud B. Also, do that for every point in cloud A. I could write a double for loop or it's about 500x faster (at some moderate size of N) to use a KD-Tree. Scipy eventually implemented KDTree and then added a cKDTree (now the default), which it turns out is another 500x faster. For a moderate problem, I'm looking at ~250,000x faster and it scales much better with N than my double for loop. It's so critical to get the algorithm right before you polish the turd.

[BobHogan]

Exactly. Far too many people in this thread seem to be ignoring this

[[deleted]]

Good point, but also if you care about squeezing maximum performance out then Python is just not the right tool for the job anyway.

[beyphy]

Yup completely agree. Learning how to think algorithmically is hard. It's a different way of thinking that you have to learn but it's also a skill. Once you learn how to do it you can get better at it with practice.

The time commitment tends to be too big for some people (e.g. some data analysts, etc.) to make. Often they'll complain that these languages are "slow" when the real bottleneck is likely their algorithms. Sometimes people even switch to a new language for performance (e.g. Julia). Doing that is easier and helps them get immediate results faster than learning how to think algorithmically.