Has everyone forgotten the art of creating or using performance profiling tools
post
What if the language has a bad design?
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.
yeah, sometimes it feels like the same people complaining about python speed are the ones writing "C" code in python.
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'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
Profiling complex systems can be quite difficult. That said, I believe in the adage "Profile twice, optimize once.", adapted from the old carpenters adage of "Measure twice, cut once."
Slowness is rarely essential, but I can be far away from where you expect it.
That's what Open Telemetry is for, honestly, specifically tracing. I'm in the process of adding tracing for all of our web handlers, http client calls, database transactions/individual queries, and asynchronous jobs. Should give us a pretty good view into the performance of the system, and allow us to monitor for things like performance regressions without any dedicated profiling needed (though we certainly could add additional profiling information through Otel down the road). Since I know you're a Haskeller (recognize your handle), the hs-opentelemetryecosystem is quite solid and has integrations with a lot of libraries in the wider ecosystem, like wai, persistent, postgresql-simple, conduit, and a bunch more. I haven't needed to write too much of our own instrumentation, aside from our job system since that's a bespoke system.
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. 🤢
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."
Nah, software is slow because it runs a web engine for GUI.
I'd say a bit of both. People who are fine with having a DOM worth of overhead don't give me much confidence they are selecting algorithms well, which can absolutely affect performance and efficiency regardless of what language they are written in.
Hell, even with the optimal data structures and algorithms selected, how you set them up can make a huge difference.
Like I once had essentially a data translator that, in order to be generic, used keys in a dictionary to replace the hardcoded data structure that needed to be updated any time the spec changed, even if we didn't care about the new values.
The first version used an array of dictionaries and was slow as fuck. Each line of data would get its own dictionary and just parsing the data into this scheme took a couple minutes IIRC. Since the data was guaranteed to have the same keys each line (we were worried about changes between versions, not lines), I changed it to a dictionary of arrays, where each line would have the same index across the dicts, and it brought parse time down to several seconds. Huge difference even though big O notation would have simplified to the same expression for the two methods.
But if you pick something with a worse big O expression, it gets worse on a whole other level.
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.
The title itself is provably wrong. Take the Matrix spec / protocol, install Synapse (written in Python) and watch your 16GB ram, 4 cors shit itself live under 0 load; or run tuwunel (written in Rust) and watch it using 100MB of RAM and a single core while handling a hundred users (Dendrite written in go was also great but it's incomplete). Same for some Mastodon implementations, even Elixir wasn't great and I was disappointed.
Now if you are building some ETL or a thin API wrapper, where the bottleneck is somewhere else like a DB or another API, then yes, don't bother, Python would do.
I hate these kinds of comments that have no other purpose than to sling shit and start arguments.
Since this is a programming community (and giving you the benefit of the doubt, I assume you're not a vibe coder), you know your argument is nonsense. Writing something in Python doesn't automatically make it slow or use a lot of RAM or whatever. Synapse is shitty because Synapse is shitty. You can write slow and inefficient software in any language, and it feels really tedious to type this out because it's obvious and common sense.
You can write slow and inefficient software in any language
Yes, but you can't write snappy fast software in any language, high level languages like python, lua and php carry alot of overhead from the get go, because of dynamic typing, heavy abstractions, and heavy garbage collectors.
I don't think you're making the kind of argument you intended to make. Those are two different programs with two different development teams behind them. The design behind them (the literal thing the article is talking about) are likely completely different from each other. Comparing the languages based on two different implementations of the same spec is a bit more than disingenuous. If you want to actually compare you need to recreate the same implementation as closely as feasible. Something like this https://youtu.be/WB7v-ezqcJM
Optimising too early is the root of all evil or something like that
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.
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.
top 50 comments