8 ms·

Stupid Slow: The Perceived Speed of Computers

97 points by zdw 2y ago

sneak 2y ago
I think a lot of it is simply that systems (with the exception of games) are designed in traditional ways, which are not focused on responsiveness and frame rate for the end user. There’s little reason most applications used by most people couldn’t do the same 100fps that almost all video games can achieve. It’s just not a development priority, and being slow and laggy doesn’t negatively affect software revenues that much. It would be interesting to see what happens if a company like Apple took a hardline approach to application latencies the way they did with iOS system framerates and VR/AR passthrough latency. They have obviously already done this with the stack that supports the Apple Pencil, which benefits all iOS devices to some extent. It’s astounding that a $300 iPad can scroll around a map about an order of magnitude better than a brand new $50k Tesla’s console. Most development teams just don’t really care about latency and perceived snappiness. Google does because they learned early on that even gains of a dozen milliseconds have direct and measurable effects on their ad revenue.
- normie3000 2y ago
  > It would be interesting to see what happens if a company like Apple took a hardline approach to application latencies the way they did with iOS system framerates... Any more info on this? Android vs iPhone, and Android TV vs Apple TV suggests Apple is doing something very right on these small devices.
- swiftcoder 2y ago
  > It would be interesting to see what happens if a company like Apple took a hardline approach to application latencies To a great extent they already do. Native Mac/iOS apps very rarely exhibit these problems (and many companies producing native Mac apps even advertise this advantage). I don't think there's much they can do about the electron apps - they held the line a long time on iOS before letting those run in the first place.
  - whatindaheck 2y ago
    These days I explicitly go out of my way to find and run native programs. Sure they usually require a purchase but (1) devs need to eat too (2) the software is usually higher quality and (3) it’s ultimately cheaper than buying more cool hardware. If that fails I take whatever remaining Electron options, which is just Discord these days, and create a desktop web app via Safari or Orion. WebKit is much lighter on the system. Now when I fire up the company machine, which is even more spec’d out, it can feel stupid slow at times.
- eru 2y ago
  > Google does because they learned early on that even gains of a dozen milliseconds have direct and measurable effects on their ad revenue. That's mostly only on their frontpage. Android isn't necessarily all that snappy, for example. Nor is GMail (app nor website).
_carbyau_ 2y ago
My first distinct experience of WTF slowness was when Windows needed to verify Start Menu shortcuts to URLs or local network addresses. One machine having a bad day could wreck the start menu for everyone on the local business LAN. Nowadays, I still largely blame network. Seems as though everything is either verifying something over the internet before showing you the UI and/or posting telemetry on your action after you click something.
Animats 2y ago
Stupid slowness keeps creeping in. About four months ago, "bash" on Linux started having visibly slow character echo. Some update to Ubuntu 20.04 LTS added something. No idea what. Spell check? LLM-based command completion? Phoning home?
- dpkirchner 2y ago
  Have you tried running it with strace attached? I wonder if that would reveal something weird happening with each keystroke.
  - redundantly 2y ago
    +1 to strace I'd wager some clunky autocomplete addon for bash is causing it.
    - normie3000 2y ago
      I'd expect autocomplete to affect bash startup time rather than on every key press.
    - brabel 2y ago
      I installed some sort of nodejs plugin for zsh once and then forgot about it. One day, the shell became unusable (it was already slow when going to certain directories for the same reason). Luckily, zsh lets you trace what commands are being executed: https://unix.stackexchange.com/questions/565905/oh-my-zshs-prompt-is-slow-how-to-fix-this https://unix.stackexchange.com/questions/565905/oh-my-zshs-p... That showed that the stupid nodejs plugin was making network calls all the freaking time. Instant deleted it. That may be what's affecting you if you're a web developer.
- CookieCrisp 2y ago
  I would be a bit more paranoid about that then you seem to be
- swiftcoder 2y ago
  I once had a fancy bash prompt that displayed git status. Turns out that git status hits the network to check the state of the remote repo, and if you are having DNS issues, that's a 30 second timeout every time the prompt is displayed. In other words, it may not be the OS at fault here. Make sure you've double-checked all your prompt customisations and autocompletes
smallstepforman 2y ago
I’ve done a 4K UHD video editor which fits on a floppy disk (1.4Mb), with 30 OpenGL effects, 10 languages, audio pluggins, and is insanely responsive (https://raw.githubusercontent.com/smallstepforman/Medo/main/Docs/Medo.jpeg https://raw.githubusercontent.com/smallstepforman/Medo/main/...), and programmed it in 2 years working 4-8 hours a week. But it doesnt have a spell checker for 30 languages, it doesnt have a publish to social media button, it doesnt have a video tutorial, it doesnt have a collaberative network share mode, etc. These features add bloat and latency. That is the root cause of software slowness today. Apps from 20 years ago are still usable today, and are blazingly fast.
- draven 2y ago
  It's also a native app running on a lean OS, not something written in JS running on what can be thought of as a VM (Electron.) Another cause of software slowness is all the layers of abstractions. The author uses the Amiga as an example in the article. I also had a A600 and it was quite snappy because it did a lot less.
- fragmede 2y ago
  how is your app architected that drawing a button to publish to social media would slow your app down?
  - jazzyjackson 2y ago
    can't speak to the OPs situation, but I remember a case in mobile apps where if you wanted to let people log in with facebook you needed to depend on the facebook sdk which necessarily blocked the cold start of the app while phoning home, for analytics purposes naturally I think this became a discussion item because facebook servers briefly went down and a bunch of apps wouldn't open If I'm remembering it wrong, consider this a hypothetical scenario :)
  - teo_zero 2y ago
    Easy: it asks you the details of your accounts on first access, and stores them in its configuration. When launched the next time, it tries to log you in automatically. It also waits for the login to complete before drawing the button, so that it can gray it out if the login fails. Then it continuously checks the network and changes the button to reflect mutated conditions: connection lost, new messages/post...
oldandtired 2y ago
One of the basic causes for slowness is how the underlying language implementation does procedure calls. Decades ago, I looked at how Microsoft handled procedure calls and returns of data. I found the same problem elsewhere. The problem was related to copying of data. A single API call could involve (at the time) up to 100's of copy actions of the same value for each subsequent internal call. The actual processing of that data was minimal in the scheme of things. This has been a problem amongst many others over the decades and will continue to be so for the foreseeable future. Things that we did as a matter of course when resources were restricted have been dispensed with once those resource limits were exceeded. The lessons have subsequently been forgotten.
- smallstepforman 2y ago
  Nice observation.
- creshal 2y ago
  DBus is just as bad (its serialization scheme is bespoke and bloated), and people insist on putting its insanely inefficient overhead into everything so they can claim they "isolated" apps (as long as you ignore the gaping holes torn for and by dbus).
DeathArrow 2y ago
If someone told me 25 years ago that we will write complex desktop applications like Teams using Javascript I would have been worried about his sanity.
- hulitu 2y ago
  I'm still worried about the sanity of people writing web apps. /s
- paulddraper 2y ago
  A fair reaction. Also, Teams isn't written in 1999 JavaScript.
  - viraptor 2y ago
    It's not far off. We got some syntax niceties and 5 slightly different and conflicting ways to concatenate .js files from different directories a.k.a packages. Apart from standardizing some things (doesn't hugely matter for electron since it's the only target) and getting async - what has really changed?
    - paulddraper 2y ago
      Modules, iterators, async/await, localization, proxies, regex features, Promises, date functions, generators, classes, destructuring, WeakMap, strict mode, private members, BigInt, and a hundred other things. Check out: https://compat-table.github.io/compat-table/es5/ https://compat-table.github.io/compat-table/es5/ https://compat-table.github.io/compat-table/es6/ https://compat-table.github.io/compat-table/es6/ https://compat-table.github.io/compat-table/es2016plus/ https://compat-table.github.io/compat-table/es2016plus/ https://compat-table.github.io/compat-table/esintl/ https://compat-table.github.io/compat-table/esintl/ --- Not to mention that fact that Teams is actually written in TypeScript (tho compiled to JavaScript).
      - viraptor 2y ago
        I see really only: strict mode, weakmap, bind, typed arrays, maybe spread. (+ async mentioned earlier) The rest as far as I can see can be either written as your own function or babel-style compilation. Sure, today's code would be nicer/shorter, but... the language itself really didn't change that much, just how we use it / what we expect from it.
azriel91 2y ago
What I'd like is a future where software is "stupidly fast": 1. RIIR -- for native code execution performance, and correctness 2. async rust preferably -- green threads for efficient cpu usage 3. the constraint efficiency of game developers: 16 ms window to do all your processing 4. data structures sized to fit cache lines 5. vulkan/metal rendering pipeline oh my (edit: formatting)
- bombela 2y ago
  When you see how slow modern CLI tools can be, you don't need all this technology. Just think of respecting human time. The only true currency of life until we invent immortality.
- pjc50 2y ago
  > the constraint efficiency of game developers: 16 ms window to do all your processing This is the only one that really matters. It also implies a complete redesign of how "responsiveness" is handled, because the usual failure mode of slow GUIs is to get blocked on a whole cascade of updates which have to be done in series. Immediate mode GUIs are a lot better for this because the programmer knows that they can't call out to get some data; you render what you're given, either it's arrived on this frame or it hasn't.
MobiusHorizons 2y ago
A big difference is that we do very little on our computers now that is actually local to the machine. A significant percentage of the “stupid slow” actions involve waiting for a server that is usually optimized for throughput not latency if it is optimized at all. A surprising number of server workloads also have high latency disk access even though almost all laptops are running SSDs. I think we could vastly improve the performance of local software if we used the network primarily for syncing data, but operated on it locally.
- hnlmorg 2y ago
  > I think we could vastly improve the performance of local software if we used the network primarily for syncing data, but operated on it locally. Aside from niche tools like AI, that’s exactly how software works already
  - dclowd9901 2y ago
    I think they mean things like asynchronous updates of backend data that occasionally sync out of band. Most apps I’ve seen will make requests and not act “optimistically” on them, rather wait for the round trip to complete before continuing. I think the reason we don’t see this much is because you have to model your entire app on this (with multiple layers of data state and primitive types that represent sync-able states) and most apps aren’t written with that much forethought.
  - stavros 2y ago
    I don't know what software you're using, but the vast majority of software I use is SPAs (whether they need to or not), and need an internet connection to even load.
    - amonith 2y ago
      But that's exactly the point of SPAs - they load once and run locally even when changing "pages", syncing just data. It's just like a normal desktop app embedded in the browser page. If they expose the PWA manifest they can also be installed so that they won't require the internet even for the initial load. The old school MPAs were the ones that required the network for every single interaction.
PlunderBunny 2y ago
Perhaps, rather than saying that older operating systems felt faster, and then getting into the weeds debating that (or quoting cold, hard numbers) we should change our terminology: I’d say that older operating systems felt ‘snappier’, which I think is quite different from ‘faster’. (Side note: I would do unspeakable things for a macOS 9 GUI on a modern, lean OS, plus some cloud integration. That’s all I want, until I think of something else).
- amonith 2y ago
  I feel insane reading that older systems felt faster/snappier. Especially before SSDs everything was super slow. You'd wait for a minute to boot the system, load up a game or anything other substantial. Then of course all of the app crashes, hang ups, blue screens, kernel panics or other mandatory restarts that basically are all gone now on every major OS that we're for some reason not counting. It's super stable and fast now.
  - mrob 2y ago
    Old machines felt faster because the delays better matched our intuitive mental model of what should be difficult. Displaying a single letter when you type should be instant because that's conceptually a very simple task. Switching between open applications should be instant because you can already see them both loaded. Opening a new application can be slow, because that's equivalent to getting up and fetching a new tool from your tool box. If you wanted instant access to it you would have left it on your workbench (left it running).
sbuttgereit 2y ago
Seeing this reminds me of a wonderful talk by the late, great Joe Armstrong (co-inventor of Erlang): "The Mess We're In" https://www.youtube.com/watch?v=lKXe3HUG2l4 https://www.youtube.com/watch?v=lKXe3HUG2l4
mwcampbell 2y ago
I wonder if the bigger cause of stupid slowness in our current bad software is Electron, or misuse of declarative UI frameworks like React.
boristsr 2y ago
Reminds me of my experience learning microcontrollers last year. You strip away many of the layers of abstraction and remember just how fast computers truly are and how much work they can do every second.
alexeiz 2y ago
Software products these days are being written quick and dirty to be released as fast as possible to capture the market. Nobody has time to create quality software because by the time you finish your product, your users will already be using your competitor's product which may be horribly slow and buggy and a memory hog, but it was released a year earlier than your product. So there you go. "Release fast, improve later" is the motto of the software companies today.
kristianp 2y ago
Stupid slow startups times are the realm of MS programs like Excel, Word and SSMS (SQL Server Management Studio). Each upgrade of these programs produces longer loading times. I can only assume there's some serious synchronous phoning home going on with ssms at least. The article starts talking about windows, but doesn't have any examples of windows apps. I would tend to agree about the bloat, but I assume that a machine running windows 95 and 4MB of RAM was pretty responsive except for the occasional disk paging and as long as you didn't have multiple large apps going at the same time.

97 points by zdw 2y ago

I think a lot of it is simply that systems (with the exception of games) are designed in traditional ways, which are not focused on responsiveness and frame rate for the end user. There’s little reason most applications used by most people couldn’t do the same 100fps that almost all video games can achieve. It’s just not a development priority, and being slow and laggy doesn’t negatively affect software revenues that much. It would be interesting to see what happens if a company like Apple took a hardline approach to application latencies the way they did with iOS system framerates and VR/AR passthrough latency. They have obviously already done this with the stack that supports the Apple Pencil, which benefits all iOS devices to some extent. It’s astounding that a $300 iPad can scroll around a map about an order of magnitude better than a brand new $50k Tesla’s console. Most development teams just don’t really care about latency and perceived snappiness. Google does because they learned early on that even gains of a dozen milliseconds have direct and measurable effects on their ad revenue.

normie3000 2y ago
> It would be interesting to see what happens if a company like Apple took a hardline approach to application latencies the way they did with iOS system framerates... Any more info on this? Android vs iPhone, and Android TV vs Apple TV suggests Apple is doing something very right on these small devices.
swiftcoder 2y ago
> It would be interesting to see what happens if a company like Apple took a hardline approach to application latencies To a great extent they already do. Native Mac/iOS apps very rarely exhibit these problems (and many companies producing native Mac apps even advertise this advantage). I don't think there's much they can do about the electron apps - they held the line a long time on iOS before letting those run in the first place.
- whatindaheck 2y ago
  These days I explicitly go out of my way to find and run native programs. Sure they usually require a purchase but (1) devs need to eat too (2) the software is usually higher quality and (3) it’s ultimately cheaper than buying more cool hardware. If that fails I take whatever remaining Electron options, which is just Discord these days, and create a desktop web app via Safari or Orion. WebKit is much lighter on the system. Now when I fire up the company machine, which is even more spec’d out, it can feel stupid slow at times.
eru 2y ago
> Google does because they learned early on that even gains of a dozen milliseconds have direct and measurable effects on their ad revenue. That's mostly only on their frontpage. Android isn't necessarily all that snappy, for example. Nor is GMail (app nor website).

_carbyau_ 2y ago

My first distinct experience of WTF slowness was when Windows needed to verify Start Menu shortcuts to URLs or local network addresses. One machine having a bad day could wreck the start menu for everyone on the local business LAN. Nowadays, I still largely blame network. Seems as though everything is either verifying something over the internet before showing you the UI and/or posting telemetry on your action after you click something.

Animats 2y ago

Stupid slowness keeps creeping in. About four months ago, "bash" on Linux started having visibly slow character echo. Some update to Ubuntu 20.04 LTS added something. No idea what. Spell check? LLM-based command completion? Phoning home?

dpkirchner 2y ago
Have you tried running it with strace attached? I wonder if that would reveal something weird happening with each keystroke.
- redundantly 2y ago
  +1 to strace I'd wager some clunky autocomplete addon for bash is causing it.
  - normie3000 2y ago
    I'd expect autocomplete to affect bash startup time rather than on every key press.
  - brabel 2y ago
    I installed some sort of nodejs plugin for zsh once and then forgot about it. One day, the shell became unusable (it was already slow when going to certain directories for the same reason). Luckily, zsh lets you trace what commands are being executed: https://unix.stackexchange.com/questions/565905/oh-my-zshs-prompt-is-slow-how-to-fix-this https://unix.stackexchange.com/questions/565905/oh-my-zshs-p... That showed that the stupid nodejs plugin was making network calls all the freaking time. Instant deleted it. That may be what's affecting you if you're a web developer.
CookieCrisp 2y ago
I would be a bit more paranoid about that then you seem to be
swiftcoder 2y ago
I once had a fancy bash prompt that displayed git status. Turns out that git status hits the network to check the state of the remote repo, and if you are having DNS issues, that's a 30 second timeout every time the prompt is displayed. In other words, it may not be the OS at fault here. Make sure you've double-checked all your prompt customisations and autocompletes

smallstepforman 2y ago

I’ve done a 4K UHD video editor which fits on a floppy disk (1.4Mb), with 30 OpenGL effects, 10 languages, audio pluggins, and is insanely responsive (https://raw.githubusercontent.com/smallstepforman/Medo/main/Docs/Medo.jpeg https://raw.githubusercontent.com/smallstepforman/Medo/main/...), and programmed it in 2 years working 4-8 hours a week. But it doesnt have a spell checker for 30 languages, it doesnt have a publish to social media button, it doesnt have a video tutorial, it doesnt have a collaberative network share mode, etc. These features add bloat and latency. That is the root cause of software slowness today. Apps from 20 years ago are still usable today, and are blazingly fast.

draven 2y ago
It's also a native app running on a lean OS, not something written in JS running on what can be thought of as a VM (Electron.) Another cause of software slowness is all the layers of abstractions. The author uses the Amiga as an example in the article. I also had a A600 and it was quite snappy because it did a lot less.
fragmede 2y ago
how is your app architected that drawing a button to publish to social media would slow your app down?
- jazzyjackson 2y ago
  can't speak to the OPs situation, but I remember a case in mobile apps where if you wanted to let people log in with facebook you needed to depend on the facebook sdk which necessarily blocked the cold start of the app while phoning home, for analytics purposes naturally I think this became a discussion item because facebook servers briefly went down and a bunch of apps wouldn't open If I'm remembering it wrong, consider this a hypothetical scenario :)
- teo_zero 2y ago
  Easy: it asks you the details of your accounts on first access, and stores them in its configuration. When launched the next time, it tries to log you in automatically. It also waits for the login to complete before drawing the button, so that it can gray it out if the login fails. Then it continuously checks the network and changes the button to reflect mutated conditions: connection lost, new messages/post...

oldandtired 2y ago

One of the basic causes for slowness is how the underlying language implementation does procedure calls. Decades ago, I looked at how Microsoft handled procedure calls and returns of data. I found the same problem elsewhere. The problem was related to copying of data. A single API call could involve (at the time) up to 100's of copy actions of the same value for each subsequent internal call. The actual processing of that data was minimal in the scheme of things. This has been a problem amongst many others over the decades and will continue to be so for the foreseeable future. Things that we did as a matter of course when resources were restricted have been dispensed with once those resource limits were exceeded. The lessons have subsequently been forgotten.

smallstepforman 2y ago
Nice observation.
creshal 2y ago
DBus is just as bad (its serialization scheme is bespoke and bloated), and people insist on putting its insanely inefficient overhead into everything so they can claim they "isolated" apps (as long as you ignore the gaping holes torn for and by dbus).

DeathArrow 2y ago

If someone told me 25 years ago that we will write complex desktop applications like Teams using Javascript I would have been worried about his sanity.

hulitu 2y ago
I'm still worried about the sanity of people writing web apps. /s
paulddraper 2y ago
A fair reaction. Also, Teams isn't written in 1999 JavaScript.
- viraptor 2y ago
  It's not far off. We got some syntax niceties and 5 slightly different and conflicting ways to concatenate .js files from different directories a.k.a packages. Apart from standardizing some things (doesn't hugely matter for electron since it's the only target) and getting async - what has really changed?
  - paulddraper 2y ago
    Modules, iterators, async/await, localization, proxies, regex features, Promises, date functions, generators, classes, destructuring, WeakMap, strict mode, private members, BigInt, and a hundred other things. Check out: https://compat-table.github.io/compat-table/es5/ https://compat-table.github.io/compat-table/es5/ https://compat-table.github.io/compat-table/es6/ https://compat-table.github.io/compat-table/es6/ https://compat-table.github.io/compat-table/es2016plus/ https://compat-table.github.io/compat-table/es2016plus/ https://compat-table.github.io/compat-table/esintl/ https://compat-table.github.io/compat-table/esintl/ --- Not to mention that fact that Teams is actually written in TypeScript (tho compiled to JavaScript).
    - viraptor 2y ago
      I see really only: strict mode, weakmap, bind, typed arrays, maybe spread. (+ async mentioned earlier) The rest as far as I can see can be either written as your own function or babel-style compilation. Sure, today's code would be nicer/shorter, but... the language itself really didn't change that much, just how we use it / what we expect from it.

azriel91 2y ago

What I'd like is a future where software is "stupidly fast": 1. RIIR -- for native code execution performance, and correctness 2. async rust preferably -- green threads for efficient cpu usage 3. the constraint efficiency of game developers: 16 ms window to do all your processing 4. data structures sized to fit cache lines 5. vulkan/metal rendering pipeline oh my (edit: formatting)

bombela 2y ago
When you see how slow modern CLI tools can be, you don't need all this technology. Just think of respecting human time. The only true currency of life until we invent immortality.
pjc50 2y ago
> the constraint efficiency of game developers: 16 ms window to do all your processing This is the only one that really matters. It also implies a complete redesign of how "responsiveness" is handled, because the usual failure mode of slow GUIs is to get blocked on a whole cascade of updates which have to be done in series. Immediate mode GUIs are a lot better for this because the programmer knows that they can't call out to get some data; you render what you're given, either it's arrived on this frame or it hasn't.

MobiusHorizons 2y ago

A big difference is that we do very little on our computers now that is actually local to the machine. A significant percentage of the “stupid slow” actions involve waiting for a server that is usually optimized for throughput not latency if it is optimized at all. A surprising number of server workloads also have high latency disk access even though almost all laptops are running SSDs. I think we could vastly improve the performance of local software if we used the network primarily for syncing data, but operated on it locally.

hnlmorg 2y ago
> I think we could vastly improve the performance of local software if we used the network primarily for syncing data, but operated on it locally. Aside from niche tools like AI, that’s exactly how software works already
- dclowd9901 2y ago
  I think they mean things like asynchronous updates of backend data that occasionally sync out of band. Most apps I’ve seen will make requests and not act “optimistically” on them, rather wait for the round trip to complete before continuing. I think the reason we don’t see this much is because you have to model your entire app on this (with multiple layers of data state and primitive types that represent sync-able states) and most apps aren’t written with that much forethought.
- stavros 2y ago
  I don't know what software you're using, but the vast majority of software I use is SPAs (whether they need to or not), and need an internet connection to even load.
  - amonith 2y ago
    But that's exactly the point of SPAs - they load once and run locally even when changing "pages", syncing just data. It's just like a normal desktop app embedded in the browser page. If they expose the PWA manifest they can also be installed so that they won't require the internet even for the initial load. The old school MPAs were the ones that required the network for every single interaction.

PlunderBunny 2y ago

Perhaps, rather than saying that older operating systems felt faster, and then getting into the weeds debating that (or quoting cold, hard numbers) we should change our terminology: I’d say that older operating systems felt ‘snappier’, which I think is quite different from ‘faster’. (Side note: I would do unspeakable things for a macOS 9 GUI on a modern, lean OS, plus some cloud integration. That’s all I want, until I think of something else).

amonith 2y ago
I feel insane reading that older systems felt faster/snappier. Especially before SSDs everything was super slow. You'd wait for a minute to boot the system, load up a game or anything other substantial. Then of course all of the app crashes, hang ups, blue screens, kernel panics or other mandatory restarts that basically are all gone now on every major OS that we're for some reason not counting. It's super stable and fast now.
- mrob 2y ago
  Old machines felt faster because the delays better matched our intuitive mental model of what should be difficult. Displaying a single letter when you type should be instant because that's conceptually a very simple task. Switching between open applications should be instant because you can already see them both loaded. Opening a new application can be slow, because that's equivalent to getting up and fetching a new tool from your tool box. If you wanted instant access to it you would have left it on your workbench (left it running).

sbuttgereit 2y ago

Seeing this reminds me of a wonderful talk by the late, great Joe Armstrong (co-inventor of Erlang): "The Mess We're In" https://www.youtube.com/watch?v=lKXe3HUG2l4 https://www.youtube.com/watch?v=lKXe3HUG2l4

mwcampbell 2y ago

I wonder if the bigger cause of stupid slowness in our current bad software is Electron, or misuse of declarative UI frameworks like React.

boristsr 2y ago

Reminds me of my experience learning microcontrollers last year. You strip away many of the layers of abstraction and remember just how fast computers truly are and how much work they can do every second.

alexeiz 2y ago

Software products these days are being written quick and dirty to be released as fast as possible to capture the market. Nobody has time to create quality software because by the time you finish your product, your users will already be using your competitor's product which may be horribly slow and buggy and a memory hog, but it was released a year earlier than your product. So there you go. "Release fast, improve later" is the motto of the software companies today.

kristianp 2y ago

Stupid slow startups times are the realm of MS programs like Excel, Word and SSMS (SQL Server Management Studio). Each upgrade of these programs produces longer loading times. I can only assume there's some serious synchronous phoning home going on with ssms at least. The article starts talking about windows, but doesn't have any examples of windows apps. I would tend to agree about the bloat, but I assume that a machine running windows 95 and 4MB of RAM was pretty responsive except for the occasional disk paging and as long as you didn't have multiple large apps going at the same time.