I have to constantly close my browser on a 12-core Intel Mac MINI just because four open sites get its fan spinning like it's a Hoover Dam turbine.
This just isn’t true: optimizing for speed is always a trade-off and, when an application is fast enough, it can be wasteful to focus on speed rather than other factors
Modern uses forced a lot of layers for genericity and security ..
That’s a pretty bad idea in general. Handling priorities properly is absolutely essential for the stability of a system. I’m not familiar with Amiga, but systems weren’t known for their stability back then. Whole OS crashes were much much more common back then.
There's plenty about Amiga that is and/or feels instant. My workhorse is a 14 MHz A1200 and I use it at least once a week, so I get plenty of opportunity to compare. For its intended use cases, most things feel very snappy. Then there are of course areas where it doesn't stand a chance compared to a modern PC, even if the workload is "Amiga sized". Decompression and picture downsampling, for example.
Plus web and mobile developers have put a ton of work into animations and things like that to make slowness feel natural, which lowers expectations even further. Nobody expects a device to respond quickly. You expect to have to wait a bit for round-trips or animations or both.
I cover this in "Your Database Skills Are Not 'Good to Have'": https://renegadeotter.com/2023/11/12/your-database-skills-ar...
Specifically when I cite THIS: https://designingforperformance.com/performance-is-ux/
possibly it might not be smart enough to reorder an index on (field1, field2), or it had some weird internal constraint on tuple ordering, or it was simply different enough to go down a different query plan sometimes, or maybe there’s something around the actual physical ordering on disk?
but yeah postgres and SQLite are modern marvels that we take for granted… myISAM was not a good time, or at least people tended to violate the correctness/visibility rules it promised (iirc) or something like that. The fact that you can just open up a stable, well-tested sql instance that runs against disk, or drop Postgres into most transactional use-cases, and generally not have to worry about unduly fighting the DB itself, is underappreciated.
This is looking at the problem wrong.
I notice your shittily optimised application not just because it’s slow, but because it’s draining the battery.
This is a problem, and developers need to wake up to it. Crappy performance uses more energy because the machine is doing unnecessary work to an end that could be achieved more efficiently, often much more efficiently.
So, please, invest time in performance.
Burning up a laptop CPU and torching racks of servers and routers in some data center just because the web is full of shitty ui frameworks should be intolerable to consumers and providers. Efficiency really needs to be a goal of all system designers.
IMO Product Managers should be steering resources based on what end users want rather than what we feel they should want. Now if we could just get more of them to listen to actual users more than marketing people that are more interested in growing their list of feature bullet points than making software that's useful to anybody at all.
What we can increase is parallelism, but most problems simply can’t be parallelized for a good enough percentage of the workload, and Amdahl’s law can’t be circumvented.
Nonetheless, many other things can be scaled, like resolution (like, think how much bigger 4k@120fps vs hd@60fps is), file sizes, etc, so the workload does increase and not everything can cancel out, hence the perceived slow down in certain cases.
I find dismissive statements like this to be extremely useless to the conversation. I agree that a modern operating system could be blazing fast. But if that’s not the case, then there obviously is a reason.
If you know the reason why software in general has gotten slower (compatibility?, bad devs?, more feature?), and already dismissed it as an invalid or insufficient reason, then share what you think that reason is.
If you, like me, don’t know what that reason is, then let’s approach it with a problem-solving attitude and try to find out.
There isn't a singular cause to brainstorm. It's everything in the entire stack optimizing just a bit in other directions that produces the end result of disappointing, sluggish computers despite their actual capabilities. This discussion isn't going to tread any new ground either. All of these things are known because there are people who can't afford modern computing, like the HFT firms that are all on FPGAs now and real-time embedded systems. It's not hard to do, it's just tedious and expensive the way development used to be for everyone.
Most desktop software just doesn't give a shit about performance.