These days, you have the real possibility the program(s) have a limited life span before the next upgrade. With today's hardware, you can bet you will get more performance per $ spent than by changing the software.
IIRC, I think RMS said something like "do not worry about performance, hardware will catch up". In the case of Emacs, it definitely did.
The amount of money spent on software development was a lot smaller and there were far fewer programmers. And they were creating a lot of bloated nonsense that you could install on your 8086, commodore 64, or whatever. Windows 1.0 is a good example. That was released nearly 35 years ago.
These days the one thing that's different is that hardware ages a lot slower. I've been on several laptops with 16GB since 2012. Back in 2012 that was a lot. Now Apple seems to still find 8GB more than enough for anyone (Bill Gates pun intended). Things are moving much slower with hardware.
I remember reading years ago about how people kept asking microsoft's engineers why Visual Studio hadn't been updated to be a 64 bit native app. They said they didn't need to - if visual studio ever gets anywhere near the 3gb memory limit (or whatever it is) on 32 bit windows apps, they spend the time to optimise the application. As a result, there is / was simply no benefit to have the program running in 64 bit mode. Even for massive projects, it simply doesn't need the larger address space.
Nowadays,hardware performance is increasing at 10% per generation https://www.cpubenchmark.net/singleThread.html
Do you see your hardware getting significantly better at each gen?
With today’s hardware and today’s cost of software engineers…
Bloomberg terminal and some point-of-sale systems were well regarded on interactive performance. What tooling was used to optimize their performance?
If we can use LLMs to rewind/recall activity, can we use continuous profiling (e.g. eBPF) to identify interactive hotspots in complex user workflows?
I once worked with a taxi company whose despatch system ran on QNX. During peak hours average call times were around six seconds and the system had to be very low latency and reliable. The UI was designed entirely on getting the relevant information from the caller and into the system in that six second window. It was text-only, made heavy use of keyboard shortcuts, and used predictive text before that was even a thing.
The “industry” can design performant systems when there’s money on the table.
But I think we only have performance because we're spoiled for choice. People just wouldn't use these tools if they were slow. (Or they'd get fixed). In other industries, thats just not the case.
I have a friend in Australia who's a doctor. Apparently the computer system they use to look up medical records sometimes just freezes for 30 seconds at a time while it does who knows what. Its a real operational problem. But the procurement process is so complex that it'd be almost impossible to get someone who knows what they're doing to come in and fix the issue. Or hospital could move systems - but that'd probably cost them millions of dollars. Its crazy.
