Why software gets slower on the same hardware

The options around software bloat are set out side by side below, with the conditions that genuinely favour one over the other.

Each layer is individually justified

Frameworks, runtimes and cross-platform toolkits exist because they let a small team ship on several platforms at once. Each adds indirection, memory overhead and startup cost, and each is defensible on its own. The problem is that the costs stack while the justifications are evaluated one at a time.

This is a straightforward economic outcome rather than carelessness: developer time is expensive and hardware is cheap.

Many desktop apps are browsers

A large share of modern desktop applications bundle a full browser engine and run a web application inside it. That means a chat client can consume hundreds of megabytes of memory to display text, because it is carrying a rendering engine, a JavaScript runtime and a networking stack.

At the protocol level, the alternative — native applications per platform — costs several times the development effort, which is why almost nobody chooses it. The engine is bundled per application rather than shared between them, so a machine running five such programs holds five separate copies of substantially the same runtime at the same time.

Memory is used because it is there

Caching aggressively is rational when memory is plentiful, and every application makes that decision independently. The result is that total demand rises to fill whatever is installed, and a machine with more memory does not feel proportionally faster. Operating systems compress and swap to manage this, which is why memory pressure shows up as sluggishness rather than as failure.

Compression buys space with processor cycles, so a machine under memory pressure also runs warmer and drains its battery faster, and those symptoms get investigated as though they were unrelated problems.

Perceived speed is mostly latency

Users notice the delay between an action and a visible response far more than raw throughput. An application that draws something immediately and fills in detail later feels faster than one that waits and then draws everything.

This is why perceived performance work often produces bigger wins than optimisation of the underlying operation. It has a failure mode: a placeholder layout that reflows once real data arrives moves the content under a finger already reaching for it, which measures as faster and is experienced as worse.

What actually helps a slow machine

Reducing the number of applications that run at startup addresses memory pressure directly and is usually the largest single win. Replacing a mechanical disk with solid state remains transformative on older machines and dwarfs most other upgrades.

The short version: adding memory helps specifically when the machine is swapping, and does very little when it is not. When hardware changes have run out, switching to a lighter application or a browser version of the same tool is what remains, because the binding constraint is what the software expects rather than what the machine can do.

Starting up and running are different problems

Before a program responds at all it must be read from storage, have its runtime initialised and its interface constructed, and none of that is improved by how efficiently it runs afterwards. Vendors hide the cost with background services that keep parts of the application permanently resident, which spends everyone else's memory to buy one application's launch time.

The short version: several of these services on one machine compete for the same resident space, and the cost lands on whichever program did not install one. Turning them off makes the favoured application slower to open and frequently makes the machine as a whole feel better, which is a trade most people would take if they were ever asked.

Side by side

The takeaway

Nobody decided to make it slower. Everybody decided to save a week.

The constraint is almost always physical, and marketing rarely mentions which one.