Noah Kochavi's blog

Software bloat (2026)

What is software bloat?

Throughout my life, and the decades before, I have heard over and over again about the advances in computer hardware. I have studied how computers execute instructions, designed simple ones in RTL, and seen them get faster over time, mostly due to making use of the advances in semiconductor nodes. However, software has, on average, remained roughly the same speed and proportional memory usage throughout my lifetime, as seen in Wirth’s Law.

But, as with personal hardware upgrades, the slowdown does not usually happen gradually on a software-by-software basis. Things that used to be very fast are now moderate, and things that used to be moderate are now very slow, even if the number of features stays the same (or decreases!). There are so many examples of this, here are a few I can think of:

I find this quite sad. These are just modern examples over the past few years, but we used to get by with a full desktop OS with well under 1% of the hardware resources we have on today’s budget hardware.

I used to think as a kid that the hardware somehow got slower with time. Later I found out that it was the software getting slower, not the hardware.

What is causing software bloat?

In all my scouring, I have found 2 primary reasons why software has gotten so much slower and space-intensive over the years.

  1. We expect more out of computers today than before. This is partially due to extra features, which are sometimes themselves unnecessary (see feature creep). In 1996, the typical screen resolution was 640x480, with a 8 or 16 bit color depth. Now, we have multi-monitor setups, often consisting of 1920x1080 at the low end up into the 4K range, with 24 bit or greater color depth, and with refresh rates that can be sky-high (my gaming laptop has a 300Hz refresh rate, for example). This takes more memory and more computation to run smoothly. However, unless you have bottom-of-the-barrel computing hardware, a difference in struggling is not very noticible between different resolutions for non-graphics-intensive applications.
  2. The much bigger reason, in my opinion, is that developers have relentlessly optimized for cost and developer experience over performance. The most lightweight, performant way to write GUI apps in Windows was Win32, but it was tedious and confusing to newcomers. In 2002, Microsoft released WinForms, a toolkit to write GUI apps using drag-and-drop and C#. It was easy enough that I used it for a train simulator group project for a class. While it was still fast, it took ~40MB of RAM, which is significantly more than it would be in Win32. However, WinForms is a Windows-only GUI toolkit! The solution? The much-maligned Electron, which wraps the app inside an entire browser runtime. Many of the slowest apps today use Electron, such as Discord, MS Teams, Spotify, and Steam, which each use hundreds of megabytes or sometimes over a gigabyte of memory.

What can be done?

In the interest of using my computer efficiently, I try to factor in the weight of apps when I download them. Let’s say I want a tool to convert opus files into mp3 files. I’ll choose something fast and native like fre:ac over something build on a more “modern” framework. Sometimes, software like this can perish, like WordPad. And, sometimes there is software that is new, feels modern, and is fast and lightweight, like Markpad.

One of the biggest ways to decrease the resource usage is to run a whole different OS, usually some form of Linux. For example, a couple years ago I ran Lubuntu on a laptop from 2009, and as long as I avoided the web browser, it was snappy and it used only 430MB of RAM on idle. Unfortunately, even this is a significant regression from a few years prior, where Lubuntu used significantly less memory. This trend is consistent among Linux distros.

The picture is less bleak on the backend, as the backend is much more focused on a single task, and you directly pay for your computing resources on the back-end. I currently use a $2/month VPS to host my blog, and its 1GB of RAM, 10GB SSD storage, and especially its single CPU core are overkill. I could easily get by with 400MB of RAM, 3GB of storage, and a Pentium III for web hosting, as long as I’m not getting more than… a couple hundred requests per second.1 The RAM and storage overheads (250MB and 2GB respectively) are a bit disappointing.

What should we strive for?

My rule of thumb is to develop for a smooth experience on budget hardware for the year (current year / 2 + 1000). So in the year 2026, I strive to develop for a smooth experience on budget hardware from 2013. The software can be native or web-based, as long as it is smooth.

This can be modified a bit to reflect current conditions. For example, RAM is the most expensive its been since 2010, so I want to take extra care that my app doesn’t use an excessive amount of memory. On the other hand, budget 2013 phones used 32-bit CPUs, and phones have lower lifespans than laptops or desktops, so I can adjust my benchmark to running smoothly on a Snapdragon 410.

Internet bloat

Additionally, bloat can be measured in size, especially for web pages. So many web pages these days take megabytes of code and sometimes useless images or videos. Unless the site is doing something impressive like showing an interactive map, all code should be under 250KB gzipped. I call this my GZ250 principle after my first motorcycle. This is a generous benchmark, as my full-fledged web games written in JavaScript are between 30KB and 60KB gzipped.

A picture of my GZ250

Webpage bloat can be even worse than CPU/RAM/Storage bloat because having stable, fast internet access in 2026 is absolutely not a given, even if you have a premium device and live in an urbanized area. I have a midrange Android phone that regularly achieves speeds only in the 100Kbps to 1Mbps range due to bad WiFi connections. My laptop and desktop, both powerful machines, sometimes just get zero bytes for seconds at a time. And yes, I live in the city! 5G has been surprisingly reliable, but it falters during sporting events or other crowds, where the competition for bandwidth sends you back to dial-up speeds. Not to mention data caps.

Conclusion

I know this was a bit of a rant, but I wanted to share one of my biggest pet peeves, and something that I have the power to do something about with my own projects.

  1. This is an estimate based on running wrk on my VPS and getting 5,000 requests per second with 10,000 active connections. ↩︎