There's no reason for software to be slow anymore

There never was. We had software that felt snappy on 90's hardware

the slowest part of most software is still the part where a human has to wait for a build to finish before they can remember what they were doing

"There's no reason" being very different than "we can now do the thing easier". There are still tons of reasons for software to be slow, the biggest of which is priorities.

If you want your software to be fast, stop writing it in Python and TypeScript and instead write it in Go, Rust, C++ or C. But nobody's going to do that, because humans are emotional creatures who get attached to things (like programming languages). Or if you want your software to be fast, stop spending your time and money (tokens) on features, and start spending it on profiling log replays to find a bottleneck causing a 50ms delay for the 95th percentile. But nobody's going to do that either, because how slow is too slow? Answer: when it's slow enough to scare the shareholders or annoy the developer on their high-powered laptop.

If you want faster/more efficient software, force it to run on a 100MHz CPU with 512KB RAM and a 56k modem. You'll definitely prioritize speed then.

Incentive has shifted. It’s now more important to worry about “developer productivity” and churning out as much code as quickly as possible than it is to spend time optimizing that code.

I recently built a piece of code which downloads a bulk set of data, indexes it for search, and then serves a pretty web UI on top of this with the help of some AIs. Normally I would have reached for sstables, sqlite, etc. This time, because the lookup patterns actually would not have been too efficient on sstables and SQLite would have been overkill, I had an agent take the data structures, pack the text effectively, and build a prefix tree for fast auto completion from the search bar. It was great. I could have done this all before but I wouldn't have. I would have felt sqlite was fast enough. The resulting web server is significantly faster feeling (because the optimized lookup speeds) than an sqlite implementation would feel like.

I think engineers building very complex systems now have a lot of performance knobs to twiddle that would have just been too costly for human effort. Since we constrain the responsibilities of the agent slop is less of a problem. We relegate it to defined tasks with clear API boundaries and test harnesses.

With RAM becoming expensive, developers will have no choice but to make memory efficient software.

i can pore all my time, agents running profiling, workloads and so but no one gives a damn. tried the whole year, still do for my personal projects

Yeah.... maybe. I think AI is still too prone to go down rabbit holes and not understand the whole picture well enough to come up with good optimisations. It's probably good at micro-optimisation, e.g. pre-allocating arrays. But is it going to realise that you don't need that array in the first place? I dunno.

On the other hand it does mean there's no excuse for writing your program using Python or Electron or whatever, which will have a big effect on performance.

Funny they mention demoscene as an example. I've tried to get various LLMs to explain or modify my demos and they utterly fail. At the extreme end this style of coding requires you to hold all understanding of what is happening end to end in your head, this x-ray vision allows you to reason and think about fundamentals without getting held back by abstractions.

LLMs operate in abstractions. "Reasoning" is bolted on.

>LLMs are causing slow, bloated, code are going to eat crow once they re-write everything in super-optimized assembly

LLMs have caused such an increase in ram prices that pine64 is no longer making linux machines. When you can't afford RAM, as a direct result of LLMs, it's going to make your assembly app slower too. Sorry, this is the future you chose.

Dan Luu might benefit from having an LLM optimize his website for readability.

> There's no reason for software to be slow anymore

There has never been. We are running supercomputers. And somehow every app is a dog-slow barely moving monstrosity incapable of showing a page of text without stuttering.

I agree with the headline, but I don't think LLMs are a reliable way of optimizing software.

First of all, coding speed is not the main bottleneck. I've been working on my own JavaScript framework. Most of my work is talking to people about challenges they have with web development, doing research on existing tools, and thinking about features to add.

Coding more slowly without LLM usage is a benefit because it helps me understand every line of code. The slower pace also helps me think about making things intuitive and reflect on my experiences with React.

While my framework is outperforming React, that isn't particularly impressive. On the other hand, it demonstrates how ignoring LLMs improves quality. Also, my monthly token spend is $0.

I see N+1 everywhere

Someone please tell me why a modern portable digital music player takes at least 10x as long to start up than its equivalent of 25 years ago.

Well, at least with the RAM crunch that the AI boom has caused, I hope there will be some sort of pressure to write efficient software, otherwise device manufacturers are quite fucked.

Sure there is. Nobody cares about quality, mvp and get to market first is what counts. AI means there is more reason for software to be slow, because it creates code more quickly and with poorer quality.

I'm a product manager. We work with Claude Code all the time, so I'm in Terminal pretty regularly. One of the developers insisted that I need to use his flavor of shell. He set it up to load automatically whenever I run Terminal, and now once the terminal window opens it takes another five seconds to get to the command line -- WTF?!

It could very well be argued that a move towards more optimized, yet still human-readable languages is appropriate. In a _very_ generic sense, LLM's can pick up the slack of those languages being harder to write, AND hard to debug.

There is less of a need for super convenient, yet bloated languages now. For software that matters, and burns the most joules in the world, I hope we can also spend a few more tokens instead of doing it in interpreted python just because it's a bit easier for the LLM.

I think this oversimplifies the problem of dealing with performance issues. In my experience, there are three aspects that contribute to the software engineering cost of performance optimizations:

1. Identifying the cause of poor performance. 2. Implementation. 3. Architectural impact (performance is a classic case of a cross-cutting concern)

(I am specifically leaving out the case of realtime systems, hard or soft, where additional factors come into play.)

But the article seems to focus entirely on the second aspect, while largely ignoring the other two.

Most performance bugs are not difficult to fix [1, 2], but can sometimes be hard to identify. Implementation effort is not the driving limitation in those cases.

Conversely, other performance improvements may affect the overall design, e.g. 27% of all bugs identified in [3].

Having an obvious, self-contained optimization target with a benchmark where algorithmic optimization within a module is also the key problem seems to be the exception, not the rule.

Also, not all performance issues are created equal. Many have trivial cost.

In contrast, some of the most challenging performance issues are the ones that affect the design and architecture of the system. After all, the hard part of software engineering is not writing a small, self-contained application. It's managing system complexity, while maintaining (in the words of Fred Brooks) conceptual integrity. Fixing performance issues is at least in this regard not fundamentally different from fixing other software defects.

Unfortunately, this is an area that is also full of trade-offs, such as performance vs. architectural simplicity, or performance in one part of the system vs. performance in another part, all of which requires judgement.

For example, you may need to bypass an abstraction boundary or reorganize abstraction boundaries to improve performance. Or you may have to special-case something while keeping duplicated code at a minimum and easy to maintain.

This is not to say that agents cannot help here, too. In fact, agents can be very helpful at e.g. identifying bottlenecks that are not directly visible in a profiler or can be used quickly do comparative evaluations of the various options for an architectural change. But solving these issues is not, like with the regex example in the article, about hillclimbing towards better performance, but involves a combination of puzzle-solving and design skill, IMHO.

And finally, even a self-contained algorithmic improvement may come with an increased maintenance burden, especially around edge cases and through increased code complexity.

[1] Jin, Guoliang & Song, Linhai & Shi, Xiaoming & Scherpelz, Joel & Lu, Shan. (2012). Understanding and Detecting Real-World Performance Bugs. Sigplan Notices - SIGPLAN. 47. 10.1145/2345156.2254075.

[2] Selakovic, Marija & Pradel, Michael. (2016). Performance issues and optimizations in JavaScript: an empirical study. 61-72. 10.1145/2884781.2884829.

[3] Zhao, Yutong & Xiao, Lu & Bondi, André & Chen, Bihuan & Liu, Yang. (2023). A Large-Scale Empirical Study of Real-Life Performance Issues in Open Source Projects. IEEE Transactions on Software Engineering. 49. 924-946. 10.1109/TSE.2022.3167628.

There's also no reason for body text spanning the whole width of my 24 inch display.

This doesn’t seem to mention that having AI aggressively optimize software will result in code that is too clever / complex to be maintained by the original human author. For something with a very stable API and can be tested to death like a regex engine it’s likely workable. Other things, not so much. We have enough trouble maintaining AI generated code _without_ aggressive optimizations as is!

There is no reason for it to be non-extensible either and depending on the use cases people might want to trade speed/optimization for more runtime customizations which will inherently be slower than pre-baked SIMD regex and whatnot.

No reason web pages need to be ugly anymore.

100% sure software in the coming years will just feel slower and slower.

One article said secure software was here because of AI, this one says it can now be performant.

Yet when I ask for code it writes, by default, both slow and insecure code that mostly works. Kinda.

As I try to get AI to rewrite it into more secure, less bloated and optimized code is when it starts to randomly crash.

Then I read articles about how AI is "moving too fast" and cry.

All we had to do was stop approving requests for developers to have 64GB of ram as a daily default.

They could have worked in 8GB of RAM but chose not to, and now the rest of us suffer as a result because we couldn’t afford $5000 dev laptops as daily drivers.

Every post by the this person, beats the record for most unreadable, most difficult to parse, smallest font, mangled and aggregated paragraphs.

Make it as harder as possible to communicate your message...I am not sure if this is supposed to pass for minimalism...but looks more lie readability hostile snobbery. Good content does not excuse contempt for the person trying to read it.

If your argument is worth attention, presenting it legibly is basic respect for the reader....

Feel like this is the equivalent of a traffic engineer standing at the grand opening of the 5th lane for the highway saying there’s no reason for traffic to be slow anymore.

That is, there’s a misunderstanding of why software (traffic) was slow in the first place, and it has nothing to do with our ability to generate code (number of lanes), even if that code is “high quality”.

I feel so nostalgic viewing this website. I love the simple old school design. we need to bring it back

Its more about discipline because you now have so much more option for that power, not just optimization. The engineer or the manager can choose more tech debt, then LLM's power is neutered because the complexity to optimize has increased by that much, and somehow evens out, and you are back to square one.

The vast majority of users - weighting by the profits they generate for software companies - obviously don't care about "slow".

And Munger's Law never cares if you hate its consequences.

But software seems to be getting slower and less user friendly by the hour.

Eppur si muove

who is Jamie Brandon

we should just have the LLM rewrite everything in Rust :D

problem solved

Eh, not sure. Very few humans do software optimization productively, so I'm not optimistic about machines built by humans, either. Every encounter I've had with agentic optimization involved trying to apply a bunch of myths to an existing code base, in a way that seemed cool (unrolling loops, eliminating apparent branches, SIMD) but which was all pointless because the only credible optimizations were going to come from doing fewer loads and taking up fewer itlb slots and stuff like that.

There are so many unwarranted ideas here... I stopped reading half-way because of it.

Eg. JIT compilers are rare because they are difficult to write. JIT compilers come with tradeoffs, they aren't an absolute boon. JIT-compiled code isn't good for short-running scripts, for example. Even normally JIT-compiled languages try to special-case parts of the code that would not benefit from compilation and interpret them instead. Another huge downside of JIT-compiled code is debugging it. JIT compilation is better for languages that don't deal with memory allocation directly, and, in general, expose fewer low-level primitives to the language user. It would be a fool's errand to make a JIT-compiled C... I bet someone tried it, but, seriously...

Another one: a solution to slow search is building an index... Boy do I have bad news for you... Even a beginner DBA knows that an index can be a curse or a blessing. There's no one size fits all solution to this.

And the author continues to misrepresent similar problems only to make his solution make sense.

The software model has to however be easy for agents to debug in a loop, then it works very well. I recently got Fable to take a desktop app (AzWriter[1] - screenshot Mac: https://imgur.com/31DBG04 + Linux https://imgur.com/1IavBvS) from about 150 Mb -> 80 - 90 Mb on a reasonably complex UI (around 40 pages of text, paginated, etc.), even beating KWrite (160Mb even on KDE, even though KWrite doesn't do pagination or complex text layout, was a surprise to me).

What was important for this was the fact that I can run JSON-defined e2e tests[2], also good to find frame-based leaks, stale-ID problems and general "program shows its using lots of memory in the task manager" (task managers are wildly inaccurate for this, as I found out).

So, I can just tell it "okay, loop this e2e.json test over and over again, use heaptrack, samply, find out why and exactly where it's slow, memory-hungry - find the section in the codebase, figure out a solution" and then let it run overnight. The biggest difficulty here is that many perf tools are still written for humans and that things like "how much memory are we using" is a wildly complex topic (lots of problems actually getting the correct number without over-allocation, memory allocator slack, OS-level page size, memory fragmentation, etc.).

But Fable was able to track down things like "LCD font hinting causes 90k allocations that are unnecessary", etc. etc. - which then also improve frame time, usually. Memory optimization + better perf pretty much go hand in hand (less allocations = more perf). I could track them down manually probably, but it would take way more time.

Having some basic understanding of data-oriented design, cache locality, memory tiering (L1/L2/L3/main RAM), does massively help with architecture decisions (e.g. Azul can use a single buffer for the entire DOM node list, in difference to normal browsers which do the more "object based" allocation model, which massively helped page breaking performance on html-to-pdf use cases[3]). Pure-functional style also helps (f(State) -> UI) because then it gets very easy to drill down exactly where things are slow and where caches are needed.

[1] https://azul.rs/ui/release/0.2.0#demos

[2] https://github.com/fschutt/azul/blob/master/e2e/css-anim-per...

[3] https://github.com/fschutt/azul/blob/master/layout/benches/f...

Note: UI Toolkit is still very WIP, docs + code are still slop, etc. - working on it. But I just wanted to add this.

What if we need pretty, rounded, softly opaque corners on all our transparent windows hovering above a gently shadowed background?

- Computer, enhance.

Software speed is actually a binary thing. If it's as fast as the user then it's good. If it's not then it's bad. Think of it like a car - in theory different cars have different accelerations and vmaxes, but in practice if you can reach max allowed speed in your country (except Germany) and overtake all other cars you want to overtake, then you're happy; if you cannot then you're not.

Here in hackernews we have a bubble of people who are very smart so they process information at high speed in general, and have lots of experience with computers, so they process computer-related information with extra speed. We're like race drivers, squeezing every single bit of performance from the car, while majority of use cases for a car is being stuck in traffic on your way to work. Those people simply don't care about performance above 150km/h because they'll never reach such speeds so putting expensive, high-performance engines is a waste of resources.

The point I'm trying to make is that if software is fast enough for average user, and most users are fucking slow, there's no business need to further optimize it. You might keep arguing "but but but back in my days apps were instant and now they suck" but users simply do not care. This is why companies put shitty, time-wasting animations even if nothing is being done in the background.

[flagged]

[flagged]

[dead]

[dead]

[dead]

[dead]

[dead]

Wow, my browser's Reader Mode saved my bacon on this one.

Otherwise, I would have left immediately.

I'm all for speedy, simple, plaintext websites, but it is a negligible amount of work in 2026 to throw some barebones CSS in and make it approachable.