Top
Best
New

Posted by Jach 17 hours ago

There's no reason for software to be slow anymore(danluu.com)
587 points | 428 commentspage 3
qsera 2 hours ago|
Yes, Seriously, where is the native versions of LLM created slack, vscode and other memory sucking Electron apps. No one should need Electron now as well..
throwaway270925 1 hour ago|
> where is the native versions of ... vscode

Those at least already exist, without the need for any LLM: Sublime Text, BBEdit, Notepad++

neo1 11 hours ago||
Just an aside. mawk 2.0 (high performance awk) has been out for about a decade. It's about 2x the performance of its predecessor mawk 1.3.4, and 4x performance of GNU awk. Practically no distro uses it, because the author Mike Brennan is not the "I maintain this code in perpetuity" guy and the mawk maintainer Thomas E. Dickey doesn't care move on from from 1.3.4.

The point is: Code needs to be maintained if it is to be relied on. I haven't heard good things about LLM's on that front.

softwaredoug 5 hours ago||
The problem is that there’s a tradeoff between MANY objectives, not just performance

You want code that’s fast, correct, stable, memory efficient, secure, usable, and more

The reason code might be slow is about product tradeoffs. It’s certainly easy to have an LLM optimize performance only, but what do you sacrifice? Is that an acceptable tradeoff?

Maybe slow code is a good idea if it’s the only way to get correct and secure code?

AlotOfReading 1 hour ago|
I've almost never seen the trade-offs you're describing cause the slowness being discussed.

Take slack for example. It's not fast, it's not correct, it's not stable, it's not memory efficient, and it's not particularly secure. There's a reasonable argument that it's usable, but that doesn't seem to have much to do with tradeoffs in their technology choices.

dkersten 7 hours ago||
> Completely agree with your closing point. Dynamic custom software, fitted to a particular workload rather than a class of workloads, seems like a very likely outcome.

I disagree with the premise that this is the desired outcome. If every piece of software is bespoke and everyone’s instance of it works slightly differently, then it’s impossible to get support or a shared knowledge of how it works. There’s no “just share the excel file”, there’s no “press the this button on the left”, there’s no “oh I use program X to solve Y” (instead you have to know what you need so the custom software can solve it, but my time in startups taught me that most users don’t know what they want or need).

yayitswei 10 hours ago||
The linked article is such a gem: You can choose how many bugs you want now https://nolanlawson.com/2026/08/16/you-can-just-choose-how-m...

Love the concept of agents adding epicycles to fix bugs. It maps closely to my experience.

belZaah 13 hours ago||
What makes large things slow is not the individual pieces of code but the way the architecture dynamically reacts to changes in the load. Sync vs async calls, buffers, parallel vs sequential processing. This includes optimizations made: do we want to wait until the call returns or do we proceed anyway and deal with the negative response later? Most developers can’t coherently (ie, with math, graphs and figures) explain, how a connection pool prevents undesirable consequences of brief spikes in incoming requests. And I’m pretty sure AI can’t either.
spockz 12 hours ago||
It can in general: https://chatgpt.com/share/6a893693-51a8-83ed-86f9-66a1f83cb1...

Whether it can apply it directly from the codebase, I’m unsure and depends on many factors.

inigyou 5 hours ago||
Can you explain that? I don't think you can explain it either.
asdfman123 15 hours ago||
What about these reasons?

- Your boss/most of the market doesn't care if your software is slightly slow

- Your boss/the market wants new features

It's easier now to slip in fun optimization features when no one's looking, but the incentives are still off.

ltbarcly3 14 hours ago|
I can't tell if you are saying the market doesn't care if your software is slow, or quoting someone else. Either way it's objectively false and that has been known for decades. Making users wait is a surefire way to make them engage with your product less, and the more you make them wait the less they will use it.

If your boss doesn't care about your software being slow he's incompetent.

https://services.google.com/fh/files/blogs/google_delayexp.p...

https://business.google.com/ca-en/think/marketing-strategies...

https://medium.com/ft-product-technology/a-faster-ft-com-10e...

https://www.pingdom.com/blog/page-load-time-really-affect-bo...

paulhebert 14 hours ago|||
The market cares. In my experience it’s harder to make your boss care.

It’s often been hard for me to make coworkers care as well which is even more frustrating.

Unless your job really prioritizes performance and builds in benchmarking people often focus on finishing a feature as fast as possible and ignore performance (and accessibility, bugs, UI polish, etc.)

asdfman123 13 hours ago|||
Experiments demonstrate that increasing web search latency 100 to 400 ms reduces the daily number of searches per user by 0.2% to 0.6%

It obviously depends a lot on what you do, but often that doesn't matter.

ltbarcly3 13 hours ago||
Do you think most websites are hitting 100ms? You are picking silly numbers. The real world case is more like 500ms vs 2.5s. The pingdom numbers suggest that is more like 5%. It's very common for pages to take over 5s to load. That is a huge bounce multiplier. I just did a search for "sony lens" on fb marketplace, and it took about 2s to load the page. This is a very very optimized page, it got some results at the top within 500ms, which was probably enough to fill above the fold on mobile (and thus seem like it was finished). however the broader search to fill the results took about 2s. When I worked at eBay searches took 2-3s routinely if they weren't warm. Getting to 100ms for a lot of very important ecommerce pages, which are critical in terms of bounce rate sensitivity, is a real engineering challenge that millions of dollars are spent on. Imagine if eBay could get 3% lower bounce on their search pages, delivering that would make multiple careers.
dat999zx 13 hours ago||
Most of the time, it's the network related stuff, requests that are slow. But with AI, devs nowadays are chasing the aesthetic vibe, cool animations, forward-backward video on the background relative to the scrolls... Which worsen the performance drastically just for a cool landing page. I mean that could be cool for landing page only but some people put all those animations in the product itself too, which is a pain to use.
killbot5000 16 hours ago||
As long as there’s a trade off between experimentation and performance, software will always be slightly too slow.
phtrivier 10 hours ago|
And now the other aspect of the trade off is token budget allocation.

The author seems to be in a situation where you can burn as many token as you want. I don't know if that's a general situation.

(Even if you don't care about the environment impact of your computations, there is a dollar bill associated, and _someone_ cares very much about that.)

I can foresee a situation where devs will have to decide on how they allocate a fixed token budget - and then, faced with the option of "burning tokens to add a new feature requested by a customer for tomorrow's demo" or "burning tokens to maybe make the app faster in some edge case", the trade off will look a lot like the ones organisations made with human dev time.

This assumes that tokens are not going to get dramatically cheaper. I can't predict the future, but I don't see a path to that (or, are local models, and "a TPU in every machine" going to make the question irrelevant?).

I can definitely see a path were tokens get massively more expensive (let's meet six months after anthropic's IPO and check :D)

0xblinq 14 hours ago|
There's no reason for sites to look super ugly, full width and unreadable anymore.
More comments...