Python performance myths and fairy tales • Hacker News Board

Re: Python performance myths and fairy tales

#211

Post by Demiurge » Thu, Aug 07, 2025, 3:12 PM UTC

weinzierl wrote: post #210

Demiurge wrote: post #112

Earlier quoted context omitted.

I love this “real work”. Real work, like writing linked lists, array bounds checking, all the error handling for opening files, etc, etc? There is a reason Python and C both have a use case, and it’s obvious Python will never be as fast as C doing “1 + 1”. The real “real work” is in getting stuff done, not just making sure the least amount of cpu cycles are used to accomplish some web form generation. Anyway, I think…

"There is a reason Python and C both have a use case [..]" If you mean historically, then yes, but I don't think there is an inherent reason why we couldn't have a language as convenient as Python and fast as C.

It seems like a lot of people are trying, it doesn’t look like they’re succeeding.

Re: Python performance myths and fairy tales

#212

Post by weinzierl » Thu, Aug 07, 2025, 3:48 PM UTC

Demiurge wrote: post #211

weinzierl wrote: post #210

Earlier quoted context omitted.

"There is a reason Python and C both have a use case [..]" If you mean historically, then yes, but I don't think there is an inherent reason why we couldn't have a language as convenient as Python and fast as C.

It seems like a lot of people are trying, it doesn’t look like they’re succeeding.

Rust is pretty close.

Re: Python performance myths and fairy tales

#213

Post by Demiurge » Thu, Aug 07, 2025, 4:51 PM UTC

weinzierl wrote: post #212

Demiurge wrote: post #211

Earlier quoted context omitted.

It seems like a lot of people are trying, it doesn’t look like they’re succeeding.

Rust is pretty close.

I don't know a single person who would agree with that, including both python and rust enthusiasts.

Re: Python performance myths and fairy tales

#214

Post by zazazx » Thu, Aug 07, 2025, 4:59 PM UTC

Whoever wrote that up would be smart to put down the computer language books for a while and brush up on their English composition skills.

(Your downvotes prove me right.)

Re: Python performance myths and fairy tales

#215

Post by whytevuhuni » Thu, Aug 07, 2025, 6:09 PM UTC

weinzierl wrote: post #210

Demiurge wrote: post #112

Earlier quoted context omitted.

I love this “real work”. Real work, like writing linked lists, array bounds checking, all the error handling for opening files, etc, etc? There is a reason Python and C both have a use case, and it’s obvious Python will never be as fast as C doing “1 + 1”. The real “real work” is in getting stuff done, not just making sure the least amount of cpu cycles are used to accomplish some web form generation. Anyway, I think…

"There is a reason Python and C both have a use case [..]" If you mean historically, then yes, but I don't think there is an inherent reason why we couldn't have a language as convenient as Python and fast as C.

I think there is indeed an inherent reason.

In order to get conciseness, you need to accept defaults that work for everyone. Those defaults might not be that great for you, but they're good enough.

In order to get performance, those "good enough defaults" are suddenly no longer good enough, and now you need to get very specific with what you're doing.

Maybe with a smart enough compiler, a high-level language could be compiled to something with very good performance, but the promise of that "sufficiently smart compiler" has yet to be fulfilled.

Re: Python performance myths and fairy tales

#216

Post by [deleted] » Thu, Aug 07, 2025, 8:49 PM UTC

Demiurge wrote: post #162

Calavar wrote: post #139

Earlier quoted context omitted.

I believe they are talking about the processor doing real work, not the programmer.

Yeah, I get it, but I found the choice of words funny, because these words can apply in the larger context. It's like saying, Python transfers work from your man hours to cpu hours :)

[deleted]

Re: Python performance myths and fairy tales

#217

Post by yunohn » Thu, Aug 07, 2025, 8:49 PM UTC

Demiurge wrote: post #213

weinzierl wrote: post #212

Earlier quoted context omitted.

Rust is pretty close.

I don't know a single person who would agree with that, including both python and rust enthusiasts.

If I had to choose, I would compare golang but definitely not rust! Too slow to compile and non-ergonomic syntax compared to Python…

Re: Python performance myths and fairy tales

#218

Post by tcfhgj » Fri, Aug 08, 2025, 6:05 AM UTC

morkalork wrote: post #77

Twirrim wrote: post #69

Earlier quoted context omitted.

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...

The overhead of copying and moving data around in Python is frustrating. When you are CPU bound on a task, you can't use threads (which do have shared memory) because of the GIL, so you end up using whole processes and then waste a bunch of cycles communicating stuff back and forth. And yes, you can create shared memory buffers between Python processes but that is nowhere near as smooth as say two Java threads workin…

GIL is a thing of the past, no?

Re: Python performance myths and fairy tales

#219

Post by igouy » Sat, Aug 09, 2025, 1:02 AM UTC

vhantz wrote: post #195

sevensor wrote: post #185

Earlier quoted context omitted.

I maintain a program written in Python that is faster than the program written in C that it replaces. The C version can do a lot more operations, but it amounts to enumerating 2^N alternatives when you could enumerate N alternatives instead. Certainly my version would be even faster if I implemented it in C, but the gains of going from exponential to linear completely dominate the language difference.

Yeah let's just compare apple to oranges

On sweetness? On sharp acidity? On weight?

Re: Python performance myths and fairy tales

#220

Post by postexitus » Mon, Aug 11, 2025, 9:46 AM UTC

ActorNightly wrote: post #109

postexitus wrote: post #26

Earlier quoted context omitted.

A more careful reading of the article is required. The first myth is "Python is not slow" - it is debunked, it is slow. The second myth is ""it's just a glue language / you just need to rewrite the hot parts in C/C++" - it is debunked, just rewriting stuff in C/Rust does not help. The third myth is " Python is slow because it is interpreted" - it is debunked, it is not slow only because it is interpreted.

>just rewriting stuff in C/Rust does not help. Except it does. The key is to figure out which part you actually need to go fast, and write it in C. If most of your use case is dominated by network latency. Overall, people seem to miss the point of Python. The best way to develop software is "make it work, make it good, make it fast" - the first part gets you to an end to end prototype that gives you a testable enviro…

He basically says just doing that doesn't help unless very careful, due to boxing/unboxing involved. If you are careful, yes it's certainly possible. I agree with your comments around how Python is useful (but not fast) - it's the most intuitive language I've ever worked with and it just works - no surprises, no weird stuff and once you get something working then you can worry about performance without actually having to rewrite everything from scratch.