Python performance myths and fairy tales • Hacker News Board

Re: Python performance myths and fairy tales

#61

Post by game_the0ry » Wed, Aug 06, 2025, 1:56 PM UTC

I know I am going to get some hate for this from the "Python-stans" but..."python" and "performance" should never be associated with each other, and same for any scripting/interpreted programming language. Especially if it has a global interpreter lock.

While performance (however you may mean that) is always a worthy goal, you may need to question your choice of language if you start hitting performance ceilings.

As the saying goes - "Use the right tool for the job." Use case should dictate tech choices, with few exceptions.

Ok, now that I have said my piece, now you can down vote me :)

Re: Python performance myths and fairy tales

#62

Post by nu11ptr » Wed, Aug 06, 2025, 1:58 PM UTC

andylei wrote: post #58

nu11ptr wrote: post #49

The primary focus here is good and something I hadn't considered: python memory being so dynamic leads to poor cache locality. Makes sense. I will leave that to others to dig into. That aside, I was expecting some level of a pedantic argument, and wasn't disappointed by this one: "A compiler for C/C++/Rust could turn that kind of expression into three operations: load the value of x, multiply it by two, and then stor…

The previous paragraph is > Another "myth" is that Python is slow because it is interpreted; again, there is some truth to that, but interpretation is only a small part of what makes Python slow. He concedes its slow, he's just saying it's not related to how interpreted it is.

I would argue this isn't true. It is a big part of what makes it slow. The fastest interpreted languages are one to two orders of magnitude slower than for example C/C++/Rust. If your language does math 20-100 times slower than C, it isn't fast from a user perspective. Full stop. It might, however, have a "fast interpreter". Remember, the user doesn't care if it is a fast for an interpreted language, they are just trying to obtain their objective (aka do math as fast as possible). They can get cache locality perfect, and Python would still be very slow (from a math/computation perspective).

Re: Python performance myths and fairy tales

#63

Post by crabbone » Wed, Aug 06, 2025, 2:00 PM UTC

Again and again, the most important question is "why?" not "how?". Python isn't made to be fast. If you wanted a language that can go fast, you needed to build it into the language from the start: give developers tools to manage memory layout, give developers tools to manage execution flow, hint the compiler about situations that present potential for optimization, restrict dispatch and polymorphism, restrict semantics to fewer interpretations.

Python has none of that. It's a hyper-bloated language with extremely poor design choices all around. Many ways of doing the same thing, many ways of doing stupid things, no way of communicating programmer's intention to the compiler... So why even bother? Why not use a language that's designed by a sensible designer for this specific purpose?

The news about performance improvements in Python just sound to me like spending useful resources on useless goals. We aren't going forward by making Python slightly faster and slightly more bloated, we just make this bad language even harder to get rid of.

Re: Python performance myths and fairy tales

#64

Post by danielrico » Wed, Aug 06, 2025, 2:01 PM UTC

game_the0ry wrote: post #61

I know I am going to get some hate for this from the "Python-stans" but..."python" and "performance" should never be associated with each other, and same for any scripting/interpreted programming language. Especially if it has a global interpreter lock. While performance (however you may mean that) is always a worthy goal, you may need to question your choice of language if you start hitting performance ceilings. As…

That's used by some people as excuse to write the most inefficient code.

Ok, you are not competing with c++, but also you shouldn't be redoing all the calculations because you haven't figured the data access pattern..

Re: Python performance myths and fairy tales

#65

Post by fragebogen » Wed, Aug 06, 2025, 2:05 PM UTC

abhijeetpbodas wrote: post #27

An earlier version of the talk is at https://www.youtube.com/watch?v=ir5ShHRi5lw (I could not find the EuroPython one).

Here's a newer one https://www.youtube.com/watch?v=1uFMW0IcZuw

Re: Python performance myths and fairy tales

#66

Post by ahoka » Wed, Aug 06, 2025, 2:07 PM UTC

game_the0ry wrote: post #61

I know I am going to get some hate for this from the "Python-stans" but..."python" and "performance" should never be associated with each other, and same for any scripting/interpreted programming language. Especially if it has a global interpreter lock. While performance (however you may mean that) is always a worthy goal, you may need to question your choice of language if you start hitting performance ceilings. As…

Have you read the fine article?

Re: Python performance myths and fairy tales

#67

Post by fpoling » Wed, Aug 06, 2025, 2:09 PM UTC

btown wrote: post #16

I think an important bit of context here is that computers are very, very good at speculative happy-path execution. The examples in the article seem gloomy: how could a JIT possibly do all the checks to make sure the arguments aren’t funky before adding them together, in a way that’s meaningfully better than just running the interpreter? But in practice, a JIT can create code that does these checks, and modern proces…

Although JS supports prototype mutations, the with operator and other constructs that make optimization harder, typical JS code does not use that. Thus JIT can add few checks for presence of problematic constructions to direct it to a slow path while optimizing not particularly big set of common patterns. And then the JS JIT does not need to care much about calling arbitrary native code as the browser internals can be adjusted/refactored to tune to JIT needs.

With Python that does not work. There are simply more optimization-unfriendly constructs and popular libraries use those. And Python calls arbitrary C libraries with fixed ABI.

So optimizing Python is inherently more difficult.

Re: Python performance myths and fairy tales

#68

Post by ActivePattern » Wed, Aug 06, 2025, 2:17 PM UTC

nu11ptr wrote: post #49

The primary focus here is good and something I hadn't considered: python memory being so dynamic leads to poor cache locality. Makes sense. I will leave that to others to dig into. That aside, I was expecting some level of a pedantic argument, and wasn't disappointed by this one: "A compiler for C/C++/Rust could turn that kind of expression into three operations: load the value of x, multiply it by two, and then stor…

A “sufficiently smart compiler” can’t legally skip Python’s semantics.

In Python, p.x * 2 means dynamic lookup, possible descriptors, big-int overflow checks, etc. A compiler can drop that only if it proves they don’t matter or speculates and adds guards—which is still overhead. That’s why Python is slower on scalar hot loops: not because it’s interpreted, but because its dynamic contract must be honored.

Re: Python performance myths and fairy tales

#69

Post by Twirrim » Wed, Aug 06, 2025, 2:19 PM UTC

aragilar wrote: post #42

dgan wrote: post #32

"Rewrite the hot path in C/C++" is also a landmine because how inefficient the boundary crossing is. so you really need "dispatch as much as possible at once" instead of continuously calling the native code

Isn't this just a specific example of the general rule of pulling out repeated use of the same operation in a loop? I'm not sure calls out to C are specifically slow in CPython (given many operations are really just calling C underneath).

The serialisation cost of translating data representations between python and C (or whatever compiled language you're using) is notable. Instead of having the compiled code sit in the centre of a hot loop, it's significantly better to have the loop in the compiled code and call it once

https://pythonspeed.com/articles/python-extension-performanc...

Re: Python performance myths and fairy tales

#70

Post by throwaway6041 » Wed, Aug 06, 2025, 2:20 PM UTC

game_the0ry wrote: post #61

I know I am going to get some hate for this from the "Python-stans" but..."python" and "performance" should never be associated with each other, and same for any scripting/interpreted programming language. Especially if it has a global interpreter lock. While performance (however you may mean that) is always a worthy goal, you may need to question your choice of language if you start hitting performance ceilings. As…

> the "Python-stans"

I think the term "Pythonistas" is more widely used

> you may need to question your choice of language if you start hitting performance ceilings.

Developers should also question if a "fast" language like Rust is really needed, if implementing a feature takes longer than it would in Python.

I don't like bloat in general, but sometimes it can be worth spinning up a few extra instances to get to market faster. If Python lets you implement a feature a month earlier, the new sales may even cover the additional infrastructure costs.

Once you reach a certain scale you may need to rewrite parts of your system anyway, because the assumptions you made are often wrong.