Comment by ModernMech
5 days ago
Exactly, most Python devs neither need nor care about perf. Most applications don't even need perf, because whether it's .1 second or .001 seconds, the user is not going to notice.
But this current quest to make Python faster is precisely because the sluggishness is noticeable for the task it's being used for most at the moment. That 6 second difference you note between the Optimal Python and the optimal Rust is money on the table if it translates to higher hardware requirements or more server time. When everything is optimal and you could still be 4x faster, that's a tough pill to swallow if it means spending more $$$.
> most Python devs neither need nor care about perf.
You do understand that's a different but equivalent way of saying, "If you care about performance, then Python is not the language for you.", don't you?
Yes, I'm consistent in that. What I don't get is if that's the case, why is there such a focus on improving Python perf? At best they're getting marginal improvements on something that most Python devs claim they don't care about, and which they say is not important for Python as a language due to JIT, C interop, and so on.
I think perhaps their hope is that eventually Python can get to Go-level if not Rust-level performance if they keep up the optimizations. I do personally believe this to be possible. The motivating example is Julia, which is a high level language with low-level language's performance. After arriving there, developers will care.
7 replies →
"Logically equivalent" is a very limited subset of "equivalent (in meaning)". Language is funny like that.