Why Python Is So Slow (And What Is Being Done About It) (thenewstack.io)

submitted 5 months ago by dominiquec@lemmy.world to c/python@programming.dev

47 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[-] Diplomjodler3@lemmy.world 35 points 5 months ago

In all the stuff I do in Python, runtime is not a consideration at all. Developer productivity is far more of a bottleneck. Having said that, I do of course see the value in these endeavours.

[-] FizzyOrange@programming.dev 9 points 5 months ago

If everyone had a magic lamp that told them whether performance was going to be an issue when they started a project then maybe it wouldn't matter. But in my experience people start Python projects with "performance doesn't matter", write 100k lines of code and then ask "ok it's too slow now, what do we do". To which the answer is "you fucked up, you shouldn't have used Python".

[-] sugar_in_your_tea@sh.itjust.works 6 points 5 months ago

No, it's usually "microservices" or "better queries" or something like that. Python performance shouldn't be an issue in a well-architected application. Source: I work on a project with hundreds of thousands of lines of Python code.

[-] FizzyOrange@programming.dev 1 points 5 months ago

Well yeah if by "well architected" you mean "doesn't use Python".

"microservices” or “better queries"

Not everything is a web service. Most of the slow Python code I encounter is doing real work.

[-] sugar_in_your_tea@sh.itjust.works 3 points 5 months ago

We also do "real work," and that uses libraries that use C(++) under the hood, like scipy, numpy, and tensorflow. We do simulations of seismic waves, particle physics simulations, etc. Most of our app is business logic in a webapp, but there's heavy lifting as well. All of "our" code is Python. I even pitched using Rust for a project, but we were able to get the Python code "fast enough" with numba.

We separate expensive logic that can take longer into background tasks from requests that need to finish quickly. We auto-scale horizontally as needed so everything remains responsive.

That's what I mean by "architected well," everything stays responsive and we just increase our hosting costs instead of development costs. If we need to, we could always rewrite parts in a faster language, provided that costs less than the development costs. We really don't spend much time at all optimizing python code, so we're not at that point yet.

That being said, I do appreciate faster-running code. I use Rust for most of my personal projects, but that's because I don't have to pay a team to maintain my projects.

[-] FizzyOrange@programming.dev 1 points 5 months ago

Matrix code is the very best case for offloading work from Python to something else though.

Think about something like a build system (e.g. scons) or a package installer (pip). There is no part of them that you can point to and say "that's the slow bit, write it in C" because the slowness is distributed through the entire thing.

[-] sugar_in_your_tea@sh.itjust.works 1 points 5 months ago

Both of those are largely bound by i/o, but with some processing in between, so the best way to speed things up is probably am async i/o loop that feeds a worker pool. In Python, you'd use processes, which can be expensive and a little complicated, but workable.

And as you pointed out, scons and pip exist, and they're fast enough. I actually use poetry, and it's completely fine.

You could go all out and build something like cargo, but it's the architecture decisions that matter most in something i/o bound like that.

[-] FizzyOrange@programming.dev 1 points 5 months ago

they’re fast enough

Strong disagree. I switched from pip to uv and it sped my install time up from 58 seconds to 7. Yeah really. If pip is i/o bound where is all that speed up coming from?

[-] sugar_in_your_tea@sh.itjust.works 1 points 5 months ago

That's pretty impressive! We have a bunch of a bunch of compiled stuff (numpy, tensorflow, etc), so I'm guessing we wouldn't see as dramatic of an improvement.

Then again, <1 min is "good enough" for me, certainly good enough to not warrant a rewrite. But I'll have to try uv out, maybe we'll switch to it. We switched from requirements.txt -> pyproject.toml using poetry, so maybe it's worth trying out the improved pyproject.toml support. Our microservices each take ~30s to install (I think w/o cache?), which isn't terrible and it's a relatively insignificant part of our build pipelines, but rebuilding everything from scratch when we upgrade Python is a pain.

[-] FizzyOrange@programming.dev 1 points 5 months ago

Yeah I was very impressed. The only problem with uv and third party tools in general is that the main reason we're using Python is because my boss didn't want people to have to install extra stuff to use it. I would prefer using Deno, but apparently a one-line rock solid install command is too much to ask compared to the mess of Python infra... smh.

[-] sugar_in_your_tea@sh.itjust.works 1 points 5 months ago

Well, I'm kind of the boss, but I inherited the Python codebase. The original reasoning was it's easier to hire/on-board people, which I think is largely true.

If it was up to me, I'd rewrite a bunch of our code to Rust. I use it for personal projects already, so I know the ecosystem. But that's a tough sale to the product team, so it's probably not happening anytime soon. I'd also have to retrain everyone, which doesn't sound fun...

However, any change I make needs to work smoothly for our devs, and we have a few teams across 3 regions. So it needs clear advantages and whatnot to go through the pain of addressing everyone's concerns.

[-] FizzyOrange@programming.dev 1 points 5 months ago

that’s a tough sale to the product team

Sounds like you're not the boss enough!

I agree Rust has a pretty steep learning curve so it's definitely reasonable to worry about people learning it, especially existing employees. Though I don't really buy the "easier to hire people" argument. There are plenty of Rust developers actively looking for Rust jobs, so I suspect you get fewer candidates but the ones you do get are higher quality and more interested.

But anyway I don't think that argument holds for Deno. Typescript is in the same difficulty league as Python. Anyone that knows Python should be able to transition easily.

[-] sugar_in_your_tea@sh.itjust.works 1 points 5 months ago* (last edited 5 months ago)

Yup, I guess not. But if I was on the product team, the customers and director ate the bosses. And on it goes up to the CEO, where the board and shareholders are the boss.

If I can justify the change, we'll do it. That's close enough for me. And I did do a POC w/ Rust and could've switched one service over, but I campaigned against myself since we got good enough perf w/ Python (numpy + numba) and I was the only one who wanted it. That has changed, so I might try again with another service (prob our gateway, we have 3 and they all kinda suck).

I'll have to check out Deno again. I remember looking at it (or something like it) a couple years ago when first announced on Reddit.

[-] FizzyOrange@programming.dev 1 points 5 months ago

Yeah I have yet to really use Deno in anger because so many people are like "but Python exists!" and unsurprisingly we now find ourselves with a mess of virtual environments and pip nonsense that has literally cost me weeks of my life.

Though if you're using Numpy that source like "proper work" not the infrastructure scripting we use Python for so I probably would go with Rust over Deno. I don't know of mature linear algebra libraries for Typescript (though I also haven't looked).

IMO probably the biggest benefit of Rust over most languages is the lower number of bugs and reduced debugging time due to the "if it compiles it probably works" thing.

[-] sugar_in_your_tea@sh.itjust.works 1 points 5 months ago* (last edited 5 months ago)

You don't have to convince me that Rust rocks. I just need to convince my team that it's worth the investment in terms of time to onboard everyone, time to port out application, and risk of introducing bugs.

We have a complex mix of CRUD, math-heavy algorithms, and data transformation logic. Fortunately, each of those are largely broken up into microservices, so they can be replaced as needed. If we decide to port, we can at least do it a little at a time.

The real question is, does the team want to maintain a Python or Rust app, and since almost nobody on the team has professional experience with low-level languages and our load is pretty small (a few thousand users; b2b), Python is preferred.