It's really not about languages. Your code has to be perfect or trivial for the language to matter.
If it's easier for you to write better algorithms in Python than in C++, than your code will probably be faster while written in Python. Because better algorithms will easily get you further than 10x in terms of performance.
> If it's easier for you to write better algorithms in Python than in C++, than your code will probably be faster while written in Python. Because better algorithms will easily get you further than 10x in terms of performance.
In practice I have not often seen this pan out - if you've got the most common case of a GUI app with tons of callbacks which update your UI in real-time, there isn't one algorithm to optimize anywhere, but instead you die a death of a thousand cuts because each callback will be marginally slower than what it would have been in C++.
Also, it's much easier to control allocations & system calls in C++ (or other native languages for what it's worth) than in Python - and in my experience preventing those is an even better pathway to getting frames rendered in less than 5 milliseconds (which is what you want to do if you have any respect for your 144hz-screen users)
I've rarely found that GUI code is ever the bottleneck. Usually it's only a problem for mousemove handlers and code that runs directly in the event loop. Most GUI apps don't even have those, unless you're writing a game.
The big problem with Python GUIs is usually that the GUI framework is often written in Python. (Or it's that things like network & parsing code gets written in Python.) The framework does a lot more heavy lifting than the app does - in particular, it's responsible for converting the system events into clicks, drag&drops, submissions, etc. for the app, and for rendering components into bitmaps. If the framework is written in C++ and just exposes a Python API, there's no problem. That's how wxPython and PyQT do it.
Well, yes. GUI usually don't require much algorithmic work so there's just not much space to loose performance because of bad algorithms.
But I've seen researchers been vastly prolific in Python. They make segmentation or registration algorithms that beet the market, and then they call us (C++ engineers) to make them "fast". Usually we do, since we're trained for that. But it's never orders of magnitude. It's like 2-3 times faster.
And there were even cases where the C++ code appeared slower in the end. Well, we use slightly different math core than the numpy does and sometimes they're doing worse.
The cases you're describing sound like cases where Python is cheating. The thing that allows Python to even be considered useful for any kind of heavier computing is that a lot of standard/popular libraries are FFI wrappers to C code.
It's an excellent deal for scientific computing, where your logic is trivial and almost all work is done in C. But it's not so rosy for user-facing applications, where it's the logic that dominates.
It's tongue-in-cheek. And also a little bit of jealousy; I wish Common Lisp felt a little less fragile around binding generation and package distribution - then I could have a high-level language that's almost as fast as C (when using SBCL implementation), that could still interface with even faster C code.
Only if you're sure that the particular algorithm you're working on is the bottleneck.
One particularly common performance pessimization is replacing an algorithm with one that has better big-O performance but a worse constant factor, and doing so where the particular O is much smaller than the number of times the function is called. People learn that hashmaps are O(1) while red-black trees are O(log N) and linear search is O(N), so they'll default to using a hashmap for a lookup table, even if the lookup table has 10 items but the keys are ~500 byte strings. (I'm guilty of this one myself, but at least I measured and fixed it.)
Then they'll call this lookup in a loop 5000 times.
Using Python or another rapid-prototyping language can be a good idea here if you take the time to profile and identify the bottlenecks, but very frequently you end up shipping it, throwing hardware at it, and then wondering why you're spending hundreds of thousands of dollars on AWS bills. Plus, a really big problem with many common Python architectures is that they use pure Python libraries & frameworks even on the critical path. (Big offenders here include using BeautifulSoup in your 1B-page web analysis or Django on your million-user website.)
Something I made the mistake of saying in interviews for a bit, but now save for beers, is that often the 'hardest part' of the project is cleaning up all of these constant factor bits. They're thankless. They're everywhere, and at some point your flame chart looks pretty damned flat. There are no big wins anymore. It's fighting for inches.
(really the 'hardest thing' about software is all of the things that are true but few believes are important. Dropping the Big O can be proven empirically)
Agreed. A good point that people often miss. We also are often in constant pursuit of the next feature, so don't have the luxury of the kinds of polishing or optimization that might get some of those real performance gains. I was a big fan of the accidentally quadratic tumblr.
It's important to remember though that not all significant performance gains come from better algorithms, I've taken an industry standard C implementation of an algorithm and improved perf (as measured on production workloads) by 30x by thinking about issues that didn't really concern the original author (in particular cache locality and realizing that the entire problem could be moved into the integer domain)
Most apps don't have heavy-weight algorithms that benefit from big-O optimization. So, performance is decided by the speed of common language elements (function calls, memory allocations). It will be more effort, and harder to make secure, but you will most likely see a performance gain when using a systems language. And even more so, C++ has more escape hatches (custom memory allocators, multi-threading) than Python.
I always saw the tradeoff more in terms of developer time: Python is faster to write but pretty much always slower to run (unless you're doing a lot of IO or mainly writing wrapper functions around compute-intensive compiled code).
I don't think a lot of people would actually use asymptotically slower algorithms when using a different language.
I actually thought about that. Not a framework but an ultra-efficient web-server. Going reductionist, a static serving web-server is just a key-value storage accessible via HTTP.
So I can run a Python script that gathers all the key-value pairs (names and pages), makes an optimized search tree out of them and spawns is out as an LLVM sheet of code. Then I only have to embed it into a trivial HTTP "answering machine", assemble it all under the target architecture as part of the deployment - and that's it.
I have more fun things to do right now, but my hosting contract expires in a year or so so I'd look for the alternatives by then.
There are a lot of these already. Serving static content quickly is not an interesting challenge any more, most of them will be able to saturate a 10GBE link over a huge number of connections. No, all the interesting effort is in dynamically assembling pages.
If it's easier for you to write better algorithms in Python than in C++, than your code will probably be faster while written in Python. Because better algorithms will easily get you further than 10x in terms of performance.