I use to use Amiga computers, I presently use Haiku - i am not trying to say those are the best OSes. But when I use Windows I am surprise how slow some functions are.
Worse, I can use two different programs in Windows and one will be dog-slow compared to the other.
I blame the use of pre-written libraries that in turn call more libraries that in turn call still more. There was a site on Windows bloat-ware, there were for example programs having multiple version of the same library link into the code even while the program only used one library ever.
Also the screen layout is runned thru a layout program/library that slows things down, the layout system is great when you are designing the system, but once you reach the point of final and fixed design there are faster ways to display it.
on the other hand, management is too often cheap, and says "It works, don't it?" and do not want to pay for the extra coding that would make so much faster.
It isn't just management. Most software ecosystems (Rust, C, c++ excluded) discourage any thinking about or tinkering with performance knowledge. You see evidence of this on stackoverflow questions, questions on reddit and twitter. Young people or new programmers curious about the fastest way to do things are always lectured about how this is not good to do. It is quite unfortunate because building some experience for how to do things fast is very useful. It isn't always correct to optimize the hell out of things, of course, but we should encourage the curiosity behind it, so that more of us have the tools to do it when it is correct to do so.
I have often found that doing things efficiently isn't really harder than doing them slow. So why not aim for software that's reasonably performant from the start? Sure you can micro-optimize to get every last nanosecond, but that's not what I'm talking about.
The Windows vs Haiku case you describe is mainly a difference in terms of development culture. In Windows you can get similar fast performance and responsiveness by using the native GUI functionality, but most desktop applications nowadays use toolkits like Qt (at best) or Electron (at worst) that reimplement a ton of functionality that the OS itself already provides and treat it as something different than what it really is.
On the other hand in Haiku everything uses the native Haiku APIs.
But from what i've seen ever since Qt and Java were ported to Haiku, a bunch of applications started relying on those to run on it instead of using the native APIs (which IMO defeats the entire point of Haiku).
Haiku does use a lot of prewritten libraries BTW, they're just hidden behind the scenes and shared among applications instead of each one bringing their own copy.
First, nobody measures performance. If they do, it is often done poorly (without using performance tools)
Second, when performance is a problem, everyone guesses on the cause. Remember how they don't measure? Well, they also will say things like "this is probably slow because of X" where X is the database, the network, a method they hate, etc.
Performance analysis requires accurate measurement.
thankfully at my work nothing goes into production without a performance eval measured at least by Lighthouse & webpagetest on Fast 3G/2015 mobile/chrome.
it's nice to be able to dictate these requirements ;)
Amiga at least, older computers were more responsive because they did less - directly attached video and keyboard hardware, no USB, no compositing video drivers, less font smoothing, and so on.
> Moreover, a modern computer with one of the slower keyboards attached can’t possibly be as responsive as a quick machine from the 70s or 80s because the keyboard alone is slower than the entire response pipeline of some older computers.
Haiku (BeOS) was always promoted on its native multithreading and responsive UI, with early demonstrations showing windows being dragged around while playing video, IIRC, it's impressive that it still holds to that.
But it also says a bit about what software people pay for and keep using - if sluggish Windows software has thrived, and BeOS crashed and burned. And then on Windows and Linux, light fast software gives way to bloaty huge sluggish software left and right.
The “leaning tower of abstractions” problem absolutely should be receiving more attention than it has been, because otherwise it’s only going to get worse. I don’t know what a fix looks like exactly, but something has to change.
Almost all of this stuff is caused by doing blocking IO on the UI thread. Unfortunately that becomes harder and harder to avoid doing by accident. And if part of the UI code or data gets paged out, there's a colossal hit to responsiveness.
Worse, I can use two different programs in Windows and one will be dog-slow compared to the other.
I blame the use of pre-written libraries that in turn call more libraries that in turn call still more. There was a site on Windows bloat-ware, there were for example programs having multiple version of the same library link into the code even while the program only used one library ever.
Also the screen layout is runned thru a layout program/library that slows things down, the layout system is great when you are designing the system, but once you reach the point of final and fixed design there are faster ways to display it.
on the other hand, management is too often cheap, and says "It works, don't it?" and do not want to pay for the extra coding that would make so much faster.