Hacker News Reader

Hacker News

Comment by 1vuio0pswjnm7 | Hacker News Reader

Full thread

1vuio0pswjnm7

"Python is Slow, And That's Fine, Because It's Fast Enough"

At least this is honest.

No matter what the script does, no matter how fast the libraries, the Python intepreter has a slow startup time.

On multiple occasions I have seen people commenting on HN argue that Python is not slow.

I think for these commenters Python is "fast enough".

For others, like me, it may not be "fast enough".

IOW, the question is not whether Python is "fast" or "slow", but whether it is "fast enough" or "too slow" for a given user.

For some users, it might not be fast enough. And that's fine.

View on HN

Python, while slow, is "fast enough" because it's super easy to add native objects for anything that's too slow. It's kind of an inversion for the usual scripting language layout with fast native code loading slow snippets of script to provide customization, and tbh that's probably the better approach for most situations. Write the 99% of your application that's not performance critical in something quick and easy and flexible, and then optimize the heck out of the remaining 1% that matters.

(Not a card carrying Python fan or anything, haven't used it in a decade, I just like this architecture.)

> IOW, the question is not whether Python is "fast" or "slow", but whether it is "fast enough" or "too slow" for a given user.

100% this. There isn't REALLY any such thing as good/bad/fast/slow/cheap/expensive, there's just "meets spec better" / "doesn't meet spec as well". Everything is relative to your requirements.

This works well for applications where you have that kind of split, but there are applications where most of the time is spent scattered around a lot of the code - and if you are in that situation in Python and need to go faster, it's an awkward place to be.

Yeah, when none of the code is tight inner loops, all of it is. Not much to do then but reimplement your program in a more efficient language... then call it from a Python script. ;)

I think one thing that makes many Python programs "fast enough" is that people have already provided a huge pile of native objects in the form of the OS and its trimmings. But this is true for other languages as well. If I were writing in C, I'd never try to rewrite any portion of the OS unless I had some otherwise insurmountable issue to overcome.

Quite a lot of programs are almost entirely bopping along from one OS or numpy call to the next, with a tiny bit of business logic thrown in. You've got a better chance of making your users happy by thinking about that business logic at a high level, than trying to optimize code that's only doing 1% of the actual work.

My use for compiled code is when there's no OS, and every nanosecond matters, e.g., working with microcontrollers.

> the Python intepreter has a slow startup time.

This really depends on your perspective. Sure, it's a lot slower than running a native binary. But it's still fast enough for interactive tools that you run often. If you compare that to java tools, for example, which take seconds if not dozens of seconds to start (gradle, I'm looking at you!), python is far better.

> (gradle, I'm looking at you!)

gradle has pretty much the worst ergonomics of any developer tool I've ever used[1], so that's a pretty low bar.

[1] e.g. "Something went wrong. Re-run with -debug or -info. Now here's 5000 lines of useless stack traces that won't help at all." Nevermind an ecosystem of plugins where it's not clear where the DSL ends and API starts, and makes it virtually impossible to locate the actual source of an error message, if you get one at all.

This time last year, I was deep into writing Gradle plugins at work.

Gradle's entire architecture is the best argument I have ever seen for why you should never use a big blob of shared mutable state when all you really needed to do was pass discrete values up and down the call stack.

Compare with Bazel. I appreciate why people bounce off of many of its strictures. But when you just look at the architecture and what it takes to develop for it, it's amazing how much easier it is to grok, while achieving a similar level of flexibility.

> it's still fast enough for Interactive tools that you run often.

Oh really?

https://www.mercurial-scm.org/wiki/OxidationPlan

> chg's very existence is because we need hg to be a native binary in order to avoid Python startup overhead. If hg weren't a Python script, we wouldn't need chg to be a separate program.

god I love Hg over git. I don't understand why git is more popular.

It's pretty easy to understand. Github.

I suspect that, back in the day, Bitbucket (which was originally hg-only) might have won out over GitHub if Git hadn't also had the huge publicity boost that comes with being written by Linus.

I don’t always know how fast will be fast enough when I start a project and the risk of needing a rewrite really puts me off Python.

This is premature optimization right

It's not always the sin it's made out to be. It's a matter of risk and cost. If there's a high risk performance will be an issue, and optimising later will have a high cost (or optimising early has a low cost), then it makes sense.

Yes and no. One of the biggest disadvantages of python is that the way people typically optimize python code is to 1. rewrite in numpy 2. rewrite in Cython (or other python compiler) 3. rewrite in C++

The problem with this workflow is that it means you end up rewriting large chunks of your code over several years in systems that have fairly different idioms. If you suspect you might in the future be performance bottle-necked, writing your code in a faster (but still productive) language to start can be a lot better because you can then improve performance more incrementally without multiple full rewrites.

I think the idea is to rewrite only the hot part in c++. If there isn't a small hot part, then yes python is a poor choice.

I don’t believe so. Choosing a language that is faster (and still productive) from the get-go has almost no cost but reduces the risk of rewrite.

I work in python all the time, and I’ve still not found a situation where this happened. Sometimes you might have specific components that you might want to write in other languages, but this is really rare unless you’re manually writing really computationally intensive or time critical procedures. Which hopefully you should know going into the project. Like if you’re rolling your own in-line audio processing you know up front that python is a bad choice. But any CRUD-like app? Python is plenty fast, especially if you’re relying on c implementations of heavy-lifting stuff.

Any CPU heavy algorithm that does not have a clear boundary to start the C/C++ part is a poor match for Python.

It's a great prototyping language. Sometimes the final product will use a better algorithm because it was found easily in Python then ported to bare metal language.

(Thinking into the wild here…) Wonder if python could be sped up by not being loaded as usual per call. Ie something more like a service with careful namespace management. I’d think something that copies what’s already in ram to new registers would be much faster.

Function calls sadly are also very slow due to heavy overhead

Reply on news.ycombinator.com