Has everyone forgotten the art of creating or using performance profiling tools
deleted by creator
Never understood the idea of, “if it needs to be fast, that part is in a faster language.” Why not just use the faster language? Most of the libraries that have Python wrappers also come with c headers. Sometimes you wind up in the reverse situation where your dependency doesn’t have a Python wrapper and now you’re stuck managing silly boilerplate. Python just feels like an extra thing in the way to wrangle for little gain.
Also, hotspot-only optimization doesn’t seem to have held up in reality, right? We can all agree that software is getting slower every day. The infrastructure is slow.
All feels like cope, through and through.
I worked at a place where a site had to show the number of members, but for some reason it didn’t show the correct number. The reason was the query to the database was wrong, I corrected it in five minutes and the boss told me to put numbers manually, increasing them until we could display the correct query result because apparently the problem was there a long time before I started working there and it would make a bad image for the company if it was so easily corrected.
On other project a friend of mine told me about things were so slow and getting slower with time. Database didn’t have keys, indexes, nothing you should expect a relational database to have.
I haven’t worked in a while because of my health issues and I can assure you I’d be happier getting paid for watering plants than working with computers.
I’d add that most of the time nobody actually measured anything. at work we inherit slow sites all the time and the first guess is always “the stack”, then you profile it and it’s one query running per item in a loop or something like that. I had the same with my own side project, was sure I needed a bigger server and after measuring the problem was somewhere else completely. measuring first is boring but it’s cheaper than any rewrite I guess
Nah, software is slow because it runs a web engine for GUI.
God, this again.
Why would that slow it down exactly? Nothing really slow about GPU accelerated graphics these days?
Would love to hear the technical reasons. You need to have UI kits for GUIs. Responsive and accessible UI kits are hard. The web solved them a decade ago and made them easier to achieve than ever before. Why invent the wheel twice?
I/O is the slowest thing ever. The more I/O dependent your app is, the slower it will be. It is not easy to make a slow web UI with zero I/O. Very easy to make a slow UI with a native toolkit and high I/O usage. Network calls are I/O. Analytics are I/O. Most enterprise apps these days demand so much analytics they effectively have spyware on their own users to optimize and A/B test against.
It still adds a lot of layers between the user and the processor.
What does that even mean? I make GUIs in web technologies, I make GUIs in godot, I make GUIs in bevy, I make GUIs in flutter, etc etc. Blink uses Skia. Flutter uses Skia. Is skia just bad? What are you even saying? What is slow about web tech, really? To me performance is almost always bad engineering choices like not understanding or handling I/O.
“layers” don’t necessarily make things appreciably slow.
Noticeable speed? Sure. But I am so pissed if a fucking todo list app is a 100mb download and consumed 300mb memory when running, all because this fucker bundles and loads a whole browser engine to render itself.
I therefore do think tech stack matters as well.
Web development and using browser renderers for GUIs is one of my most hated aspects of modern software. 🤢
Sorry guys, back in 2008, I asked a monkey’s paw for better first party software support for desktop Linux, and this is what we got.
I once did some testing comparing very simple apps built with Tauri (using system webview) and native library and the difference in memory usage was not that big. I’m looking now at a simple PDF viewer in GTK and it’s using 120MB. My app written in Tauri is using 150MB. In theory native apps will use less memory when you run a lot of them at the same time but if you check the size of native Linux app they are not that tiny. They still will easily use hundredths of MB of RAM. Simple, native todo app will easily use 150MB. Yes, badly written electron app will use way more than that but you have webview tools that are really good and not that heavy.
hundredths of MB
That would be 20 kB, 30 kB, 40 kB, I don’t think you meant that.
He is right in many aspects. However, for example Guile, Racket or SBCL Lisp are a lot faster than Python, and they are more powerful than Python while being much simpler, which makes them very interesting for prototyping algorithms.
The ideal combo for such things would be a powerful interactive language with debugging capabilities combined with Rust, perhaps even a language similar to Rust. I do not know of any easy solution for that, but it could be made work with Rust’s macro system (since the above languages all provide C ABI FFI).
Also,most of design happens when a program is written first. It is hard to re-design a larger program later, which might be one reason to re-write it. So maybe the main reason for rewriting is to get a better design, not the faster language - the faster language might be an additional reason.
Also, LLMs can produce terribly bloated Rust code - not only by a factor ten larger, but also much slower.
Also, CRUD apps are uninteresting to many programming enthusiasts, and for companies, optimizing them is only interesting if it saves them money.
Right now everyone is asking their AI agents to rewrite programs in Rust or C or assembly. This is fun, but it’s not a serious attempt at optimization.
C or assembly seems pointless and only for performance. But the reason people (re) write programs in Rust is because Rust as a language has a lot of guardrails that help make a program more stable, more correct. That reliability is the real reason for Rust. The performance is just a cherry on top.
This is actually exactly what you want in a language for AI. This is anecdotal from my side, but in my experience, an AI writing Rust will write far less sloppy crap than an AI writing Python.
Most of the argument against Rust has historically been that prototyping is slow and the language is a bother to write because the compiler makes it hard. But this only holds if humans are the bottleneck for writing the code! Rust therefore has all of the benefits but basically none of the downsides when having an AI write it.
But the reason people (re) write programs in Rust is because Rust as a language has a lot of guardrails that help make a program more stable, more correct. That reliability is the real reason for Rust.
Yeah, but then the Node-like atomic packaging runs contrary to optimization and security by shoving 500 MB of code in your cli-tool. And sure, the compiler optimizes 90% of it away. But that’s not how you build stable software.
I agree that dependencies and package management is a real problem in programming nowadays, but it is not a problem unique to Rust. In fact, I struggle to name a single popular language nowadays that doesn’t have the exact same problems.
It’s not so much “But that’s not how you build stable software.” It’s more like “But that’s not how you build software [at all today].” Modern software is powered by loads of shared packages, that’s just how all modern languages work. This is equally true for Rust and Python.
Rust still has the edge here btw. Rust libraries (crates) are often very high quality with very good documentation. The language again helps here a lot, by providing extensive tooling for automatic documentation generation. Documentation in other languages are is far less helpful or poorly written. This is also again something that helps an AI write better code (just as it helps humans write better code).
The packaging also helps elevate Rust to a high-level language, because you can build easily usable abstractions in packages that can be used in simple programs. All the complexity can be hidden away in a crate and suddenly Rust feels more like Python. I think that’s actually a good thing from package managers.
It’s not so much “But that’s not how you build stable software.” It’s more like “But that’s not how you build software [at all today].” Modern software is powered by loads of shared packages, that’s just how all modern languages work. This is equally true for Rust and Python.
You’re not wrong - all libraries with automated dependency packaging do have this problem. But you’re downplaying the scale by a lot. Javascript dependency graphs are absolutely massive. Python has a decent standard library that reduces the number of shared packages by quite a bit. There are definitely downsides to having a large standard library like Python has, but it does significantly reduce the probability of a supply chain attack compared to Javascript.
I can’t comment on Rust personally, since I don’t have much experience with the ecosystem.
The problem of JavaScript is growing far more than its initial scope. Especially since there wasn’t an official org that took care of JavaScript development, and basically the community took the initiative of providing shared libraries, each one looking at their specific problem but ignoring the whole.
Sure, yes, Rust has lots of quality libraries too. I’m thinking of doing the core in D and the GUI in Rust Slint. Plug-in protocol interface modules can be written in whatever, but Rust has some interesting libraries.
Python copium.
Software engineer and can confirm this is mostly the case. Adding a spinner or cute animation to placate users is way easier than solving fundamental issues. There are definitely teams out there that absolutely care about performance but mostly in large scale scenarios where an extra 10ms per record adds up to 3 extra hours to finish a batch.
Yes and no. It’s not usually the fault of the programming language.
But programming languages have a unique ability: The design of the language itself can and will instill bad or good habits into the code of oneself. These languages are designed pretty deliberately, so those habits are a direct consequence of the design of a language. In fact, Sean Goedecke’s own C-to-Rust example makes this point implicitly: Cantrill’s port got faster not because the redesign was really clever, but because Rust’s borrow checker and standard library actively steered him toward a more cache friendly Binary tree. There are probably many more examples out there that had a real world impact.
There are no bad languages, every language has its place somewhere. But design decisions matter.
Ship in the minimum amount of time possible, by any means, to be first to market. And this means poor design and smooshing together all kind of fat general-purpose frameworks and libraries to get something out the door.
Sure, it’s slow. Google’s landing page is 4 MB for a small graphic, a text form, and some buttons. But what are you going to do? Not use it? They won. They don’t have to fix shit.
And now with LLMs they can produce bloat faster than ever and pay even less attention to speed or quality.
“The goal was never quality software.”
Sure, it’s slow. Google’s landing page is 4 MB for a small graphic, a text form, and some buttons. But what are you going to do? Not use it? They won. They don’t have to fix shit.
This neglects to include the massive amount of additional front-end code Google (and other large tech companies) toss on their webpages for things that are purely for their own benefit while being of zero or negative value to the users. Mouse tracking, analytics, fingerprinting, and all kinds of other harmful content that tech companies put out go a long way towards reaching that 4MB figure.
…I don’t use Goog’s search, just like probably many people on Lemmy.
Google is a bad example, historically the landing page has been interestingly optimised.
Lots of corporate websites are multi-hundred MB things though you are right.
Edit I take it back, the worst ones I checked have been redesigned
I’d like you to name 1 that’s multi-hundred MB.
Can’t, I was thinking of MSN.com but they had a redesign sometime, they come in at 5.6mb now
I saw something where the NYT webside takes up over 100MB if RAM.
I wrote a program in Python to read some huge Json files. It took forever to finish. Turned out I could optimize it with some simple changes, which reduced 10 minutes to 10 seconds (not literally, just figurative) and made a difference in huge files only. Later I rewrote the program in Rust. And you know what happened? It was slower than the Python version. Only after understanding what I was doing and making right changes made the Rust version faster.
Most of the time its the design of the code or libraries that slows down. The language might play a huge role in performance, but it depends on what type of code and application it is.
I actually wanted write a blog post about this… if I still have the project data I might explain what happened. BTW this had nothing to do with Ai.
Counterpoint, I wrote a Python program that reads a load of JSON and runs regex searches over it. It was quite slow. Rewrote it in Rust as a straight 1:1 port, no algorithmic changes. 50x speedup.
I think you must have either done something very wrong or your Python program didn’t really do anything other than call Python built-ins that are actually written in C.
Did you use a profiler to find the bottlenecks? Did you try using cjson to speed up the json parsing? I would also avoid using the stdlib regex library too. It’s probably more of a convenience/reference implementation, not something to be intended for high performance. Maybe there’s a re2 wrapper for Python or a similar regex library in C with Python bindings.
Rewriting in Rust is fine, but good Python devs know how to find bottlenecks in their software and replace them with fast implementations. I’ve written plenty of performant Python code, it’s not very hard to profile and optimize. Usually the performant stuff is already written in C/C++ or Fortran anyway (numpy, PyQt, etc.)
It wasn’t a very wrong what I did in Python. I did the obvious thing. While I do not remember details, I remember it had something to do with adding items I think. But sadly I have not documented this issue, that’s on me. It was only noticeable for really huge files like 50MBytes json. Edit: Most weren’t this big, but it also combined over 100 Json files into one, so a search would search them all through and be able to save as a single file.
yeah, sometimes it feels like the same people complaining about python speed are the ones writing “C” code in python.
What about the fact that runtime startup alone auto-disqualifies python for all short-lived process use-cases?
Or the fact that you can’t do concurrency especially across the language barrier from another language without multiple python runtimes orchestrated with a queue and IPC because of possible process-wide global state and similar concerns/assumptions for any python library dependency that is not all native across its own dependency chain?
“languages are just tools” and “use the right tool for the job” were already stupid catch phrases. Pretending languages don’t matter is a big further step into this shallow faux-intellectualism masquerading as wisdom.
And we didn’t even get to low level stuff yet.
Or the fact that you can’t do concurrency especially across the language barrier from another language without multiple python runtimes orchestrated with a queue and IPC because of possible process-wide global state and similar concerns/assumptions for any python library dependency that is not all native across its own dependency chain?
This is very out of date. I haven’t written Python for over 4 years and even back then, I was using multiprocessing.Pool for pretty much all parallel processing that I ever needed. Sure, it’s doesn’t fit every use case for concurrency, but for simple stuff it’s perfectly fine.
Not only that, it’s one of the simplest parallel processing APIs I’ve ever used:
from multiprocessing import Pool def f(x): return x*x if __name__ == '__main__': with Pool(5) as p: print(p.map(f, [1, 2, 3]))It’s not outdated, and maybe you didn’t get what I was talking about, but probably because I didn’t word it well. So let me quote someone else instead:
While pure Python code should work unchanged, code written in other languages or using the CPython C API may not. The GIL was implicitly protecting a lot of thread-unsafe C, C++, Cython, Fortran, etc. code - and now it no longer does. Which may lead to all sorts of fun outcomes (crashes, intermittent incorrect behavior, etc.)
This covers the layers below python, but still doesn’t fully cover the process wide restrictions (it’s not just about thread safety, global initialization and resources are very relevant too). It also doesn’t cover the exact same problem which also exists for any layer calling into python from above, which also relies/relied on the GIL for synchronization. This means that you can’t effectively, confidently, and safely scale python without scaling the number of python runtime instances, each in its own full OS process.
The fact that
multiprocessingbecame popular, instead of just scaling/parallelizing with threads, is itself an extension of the GIL/no-GIL circus. But its not the primary point here.So not only the proposition (which someone referenced in another sub-thread) to move everything into python is in and of itself a self-defeating argument, since it proves a language being a problem (through forcing language lock-in). But even within a language (python), not all problems are solvable still.
Note that this is not all theoretical for me. In one of my previous projects, I had to call into a python library (which didn’t have an adequate alternative) from rust code (through pyo3). And I was forced to scale with multiple python runtimes, each getting one request/message at a time.
And we still didn’t get to any low-level details yet 😉
What about the fact that runtime startup alone auto-disqualifies python for all short-lived process use-cases?
While Python’s start-up time is a lot slower than a corresponding compiled program, in most cases it’s not slow enough to matter even if the process itself is short-lived:
$ hyperfine 'python3 -c "pass"' Benchmark 1: python3 -c "pass" (412 runs) mean ± σ min … max Wall Time 7.1 ms ± 0.2 ms 6.7 ms … 8.4 ms Memory 9.4 MiB ± 0.1 MiB 9.1 MiB … 9.5 MiBIf you are running a small program so often that this kind of start-up time matters, then the loop should probably already be implemented in the program itself. In line with the article’s thesis
Thanks for putting numbers. People really overblow python performance issues when it literally does not matter most times.
Yeah nah, Lua runs circles around Python both at runtime and especially at startup. I’ve made me some desktop automation scripts in Lua to call from Alfred, I had to recheck that I didn’t leave static test data in there instead of calling the script, because the results were appearing instantly.
Recently had to develop a Python project, the tests took at least ten seconds to start each single time. This is while I made over a hundred tests for my module and re-ran them after every change.
Recently had to develop a Python project, the tests took at least ten seconds to start each single time. This is while I made over a hundred tests for my module and re-ran them after every change.
Python is dog slow, but if your tests are taking 10 seconds to start (not even run!), then something is catastrophically wrong with your setup. For comparison, for one of my projects, it takes a total of 12 seconds to run nox on a clean slate, which involves setting up venvs for five major versions of Python, installing the package and its dependencies in each, and finally running the 1500 test test-suite five times
It wasn’t my project. Afaict it’s a standard pytest setup with the Litestar framework (unused in my tests) and an in-memory mock Postgre transaction with like five records per test, so choose for yourself which part of this is ‘catastrophically wrong’. However, I can indeed agree that most of it is trash.
Same approach with dozens upon dozens of tests worked snappily as heck in PHP, haven’t yet tried it with my beloved Lua.
At that point just call the person messy and move on. They just want to flex their brain.
The thing is also that you can’t separate a language from its ecosystem.
Because it is possible to write the fastest programs in C/C++ and Rust, folks that actually need the fastest performance will use these languages and will go around opening pull requests to fix performance problems in commonly-used libraries.
So, you do often end up with the most performant design anyways, just because the language itself is fast on paper.
I wrote a draft of a service that would take hours to complete. when I optimized it for multithreaded operation instead of taking hours it took around 60 seconds.
write software like you write research papers. first draft > second draft > final draft > publication
I’d love that but it’s difficult when it’s not really my project and anything that is functioning well enough gets you assigned the next ticket at work.
anything that is functioning well enough gets you assigned the next ticket at work.
Except for python.
