332
Software is slow because of bad design, not slow languages
(www.seangoedecke.com)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 23 Oct 2026
332 points (96.4% liked)
Programming
28967 readers
355 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 3 years ago
MODERATORS
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.
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's mostly because of memory cache misses. JS creates a ton of closures and has a lot of context switching. JS engines are basically a modern day miracle for how fast they are but somehow webapps are still sluggish.
Memory cache hits are destroying performance? Is this profiled or just guesswork? I don't understand how that's tied to perceived performance degradation specific to web-based toolkits like Blink and Webkit
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.
The issue is that any time you add another generic layer, it involves another layer of loops for "handle everything" tasks and lookups for "handle this specific thing" tasks. A native app could set a bunch of values for properties by changing them in a single function accessing a single data structure. You might have a single function that does the same thing using frameworks, but that function is potentially going to use accessor functions to reach down each layer to set those values where they matter plus could need to do a bunch of transformations as it traverses each layer (or maybe that's done on the render side).
So then you add a bunch of caching to improve these common scenarios and balloon memory usage, which was already inflated because those layers also need memory to store their data structures.
And these things get worse as they scale, so small scale tests still look snappy and hide how much things can grind to a crawl when it needs to handle the large or normal scale. Not to mention, if you don't have a speedy version to compare to, you might just think that it makes sense for this process to take a couple minutes because it has millions of things to do (despite running on hardware that can do billions of things per second).
So that means every single developer that has ever used Electron or CEF for something, has been making bad engineering choices?
You may have something there.
Why is how nodejs or cef does I/O worse than any other GUI toolkit's I/O layer?
I haven't gotten deep enough into it to see what's wrong, but pretty much any Electron or CEF application I've used has been pretty slow, though it could be that I have a very weak PC since I only have a Ryzen 5700 and 32 gigs of DDR4 and my NVMe drives (root and home partitions being separate physical drives) are only running on PCIe 3.0, not 4.0 or 5.0. Perhaps I ought to see if things like Steam or Discord run better if I upgrade to a mid-range PC with a Ryzen 9900x, faster RAM and faster drives, but I'm not made of money.
Games run smoothly, mind you - those don't require very beefy hardware after all. It's only extremely visually and IO demanding applications like Steam or Discord that run like absolute dogshit for me. Slack used to be pretty bad too, but I don't use it these days, don't need it. Ditto for Mattermost. I have one computer dedicated to Microsoft Teams, it's got a 12th gen i7 in it which can't really handle the task, but that's just Microsoft for you, everything they've made in the last decade has been shit.
"layers" don't necessarily make things appreciably slow.
God, this again.