this post was submitted on 15 Jun 2024
4 points (100.0% liked)

Python

6207 readers
5 users here now

Welcome to the Python community on the programming.dev Lemmy instance!

πŸ“… Events

October 2023

November 2023

PastJuly 2023

August 2023

September 2023

🐍 Python project:
πŸ’“ Python Community:
✨ Python Ecosystem:
🌌 Fediverse
Communities
Projects
Feeds

founded 1 year ago
MODERATORS
jnovinger@programming.dev
erlingur@programming.dev
4
Why Python Is So Slow (And What Is Being Done About It) (thenewstack.io)
submitted 2 months ago by dominiquec@lemmy.world to c/python@programming.dev
3 comments fedilink hide all child comments
top 3 comments
sorted by: hot top controversial new old
[–] MalReynolds@slrpnk.net 0 points 2 months ago* (last edited 2 months ago) (1 children)

When you need speed in Python, after profiling, checking for errors, and making damn sure you actually need it, you code the slow bit in C and call it.

When you need speed in C, after profiling, checking for errors, and making damn sure you actually need it, you code the slow bit in Assembly and call it.

When you need speed in Assembly, after profiling, checking for errors, and making damn sure you actually need it, you're screwed.

Which is not to say faster Python is unwelcome, just that IMO its focus is frameworking, prototyping or bashing out quick and perhaps dirty things that work, and that's a damn good thing.

[–] dgriffith@aussie.zone 0 points 2 months ago* (last edited 2 months ago) (1 children)

Generally I bash together the one-off programs in Python and if I discover that my "one off" program is actually being run 4 times a week, that's when I look at switching to a compiled language.

Case in point: I threw together a python program that followed a trajectory in a point cloud and erased a box around the trajectory. Found a python point cloud library, swore at my code (and the library code) for a few hours, tidied up a few point clouds with it, job done.

And then other people in my company also needed to do the same thing and after a few months of occasional use, I rewrote it using C++ and Open3D. A few days of swearing this time (mainly because my C++ is a bit rusty, and Open3D's C++ interface is a sparsely-documented back end to their main python front end).

End result though is that point clouds that took 3 minutes to process before in python now take 10 seconds, and now there's a visualisation widget that shows the effects of the processing so you don't have to open the cloud in another viewer to see that it was ok.

But anyway, like you said, python is good for prototyping, and when you hash out your approach and things are fairly nailed down and now you'd like some speed, jump to a compiled language and reap the benefits.

[–] sugar_in_your_tea@sh.itjust.works 1 points 2 months ago

Python is also pretty good for production, provided you're using libraries optimized in something faster. Is there a reason you didn't use Open3D's Python library? I'm guessing you'd get close to the same performance of the C++ code in a lot less time.

That said, if you're doing an animation in 3D, you should probably consider a game engine. Godot w/ GDScript would probably be good enough, though you'd spend a few days learning the engine (but the next project would be way faster).

If you're writing a performance-critical library, something compiled is often the better choice. If you're just plugging libraries together, something like Python is probably a better use of your time since the vast majority of CPU time can generally be done in a library.