Live data from Hacker News

There's no reason for software to be slow anymore

danluu.com

361–370 of 531 posts

Re: There's no reason for software to be slow anymore

#361

Earlier quoted context omitted.

This, 100%. I’ve rewritten some hydrology code in rust using codex sol to first a) profile and create comprehensive tests of the python, b) create full benchmark suites, c) create full scientific benchmark suites, then d) port to rust using a few different techniques. It works, it’s at least 5x faster, sometimes much more, and memory use is like 10x less and even less in cases where lots of map tiles are involved. Th…

> What I’m wondering now is can we reliably evolve python and have codex act as an extremely unreliable transpiler to the rust. Why you even start with Python at this point? Just write the Rust version straight up instead of porting things? Personally I used to use dynamic languages for most things, because development and maintenance is so much faster and easier, particularly for larger projects (granted you know ho…

Because it’s a port of a scientific process and that’s what the scientists work in.

Re: There's no reason for software to be slow anymore

#362
post #347

Earlier quoted context omitted.

It's particularly egregious to see the number of apps that will slow to a crawl even for things that works offline if the network is down or slow.

Being offline available/fallback and offline first are two different things

Yes, but my point is that it's an awfully shitty fallback if you need to wait 30 seconds for something to time out first.

It's one thing not to e.g. spend the extra time to ensure everything is cached and mutations are queued up. It's another thing not to do the bare minimum to ensure what is already available and working locally is gated on the network being up.

Case in point: The other day I was checking our train tickets in an app, and the network was awful, and the train tickets which the app has local copies of took 30+ seconds to appear when the network went down. Everything I needed worked once the timeouts had been hit, it was just ridiculously slow waiting for timeouts for functionality I wasn't trying to use to be hit first.

Re: There's no reason for software to be slow anymore

#363

Earlier quoted context omitted.

> What I’m wondering now is can we reliably evolve python and have codex act as an extremely unreliable transpiler to the rust. Why you even start with Python at this point? Just write the Rust version straight up instead of porting things? Personally I used to use dynamic languages for most things, because development and maintenance is so much faster and easier, particularly for larger projects (granted you know ho…

What happens when LLMs will become either too expensive or unavailable?

It's becoming increasingly evident this is not how things are going to shake out. Even without frontier models, running Qwen 3.8 27B has demonstrated for me and others a "good enough" competency at general programming. Additionally, large open weight models have proven themselves as viable alternatives and we're still in the early years of dedicated hardware

Re: There's no reason for software to be slow anymore

#364
post #243
post #44

One of the biggest causes of slowness is just waiting for web requests. The fact that so much software is either online or built using the same stack even if it isn't, puts all that software in this blocked/waiting state constantly while using it. Anyone not in the US feels this even more since so much online is US hosted, 300ms for every little interaction adds up quick. If your software has the affordance of a wait…

This is kind of a shallow assessment of "slowness". Slowness is a feeling, not a fact. Network is slow as a rule relative to other parts of the stack, but it is not usually what contributes to the feeling that your software is slow. It takes a good amount of incompetence and arrogance to cultivate that particular experience.

Fair, it's shallow because I was succinct however, I do understand the problem space more in depth than this.

But if I were to pick one single thing that would speed up the most UIs across the board, it would be poor handling of the UI in networked systems. As you noted, that doesn't mean eliminating them, it means handling the inevitable in a way that doesn't tank the UI feel.

Re: There's no reason for software to be slow anymore

#365
post #148

I've been working on a similar agentically engineered regex project called SafeRE: https://github.com/eaftan/safere https://eaftan.github.io/safere-intro/ Mine is for Java and is intended to be production grade. The first goal is to guarantee linear-time behavior to prevent ReDoS attacks. My collaborator and I have recently been optimizing it to try to surpass native RE2 in performance. It turns out optimizations are…

Looks nice! One little thing I spotted is you use Boyer Moore Horspool for fast literal search. This is actually not linear in the worst case, although it is almost always sublinear. Worst case would be a literal composed of the same character searching a text of the same character, where it becomes quadratic. You can actually search strings with character classes using Horspool if you want to, and I have some enhanc…

Reading a bit closer, you seem to track how much work is being done in Horspool on each character comparison, and then fall back to the linear KMP if the work budget is exhausted.

This will first massively slow down the Horspool scan, and then once you have done all that work, you rescan it all from the start with KMP if it is doing too much.

One little fix might be to only add to the work counter and compare it outside of the main character comparison loop.

But it would be better to use the linear version of Hashchain. It also uses KMP to make it linear, but it is fully integrated and you would not need to track the work or restart scanning at all. And its a lot faster than Horspool anyway!

Re: There's no reason for software to be slow anymore

#366
post #44

One of the biggest causes of slowness is just waiting for web requests. The fact that so much software is either online or built using the same stack even if it isn't, puts all that software in this blocked/waiting state constantly while using it. Anyone not in the US feels this even more since so much online is US hosted, 300ms for every little interaction adds up quick. If your software has the affordance of a wait…

Anyone not in the US feels this even more since so much online is US hosted, 300ms for every little interaction adds up quick. Don’t know about that, pretty much everything is hosted on Cloudflare, Azure or S3 these days and all of them have at least one CDN on each continent.

I think that "almost everyone" has a multi region cdn, but fewer have multi region application deployment, or cdn workers handling a significant portion of the application logic. My experience here may be incorrect or not generalizable, but I've rarely seen web apps that are slow due to latency loading static resources, but I've often seen slowness from high latency of the API calls and due to large static payloads.

Re: There's no reason for software to be slow anymore

#368
post #255
post #253

ChatGPT MacOSX is the only software that regularly crashes on my machine when its memory consumption for no apparent reason spins up towards 50 GB. And that software is build by some of the highest paid software engineers on the planet with full access to all the LLM compute in the world.

Yes, but it's also built by people who would rather tinker with AI than build MacOS apps. Intrinsic motivation is very hard to beat, especially in subtler areas like good UX or performant software.

They absolutely do not have AI-heads with PhDs writing the apps and general infra. I've met a guy that worked at Anthropic, and he was "just an engineer", so exactly that: a top guy, but not specifically AI focused, doing regular stuff there but with infinite access to the top of the crop AI.

Now look at what software they make. It speaks for itself.

Re: There's no reason for software to be slow anymore

#370
post #44

One of the biggest causes of slowness is just waiting for web requests. The fact that so much software is either online or built using the same stack even if it isn't, puts all that software in this blocked/waiting state constantly while using it. Anyone not in the US feels this even more since so much online is US hosted, 300ms for every little interaction adds up quick. If your software has the affordance of a wait…

To dogfood this, rent a VPS in Australia and put a test environment there. Should be about 200ms ping or a bit higher. How it runs for you is how Australian users are seeing your site, even if their last mile connection is fiber.
Post reply on HN