Hey, it’s my first post here, and I have a important point to discuss.
Firefox’s heavy disk usage
I recently grew frustrated with a bug which does not allow using a RAM disk for the Firefox profile folder, because it breaks DRM meaning basically every streaming site out there. Details about the bug here: https://bugzilla.mozilla.org/show_bug.cgi?id=1763978
This not working wouldn’t really matter if Firefox had an option to actually use RAM instead of disk for its’ data without uprooting the whole profile folder which is constantly being written in large amounts. Using a combination of every possible config option regarding to RAM/disk caching do not cut it in the current version, most of the data written still ends up to the disk as the worst culprits are the session storage and various .sqlite databases.
Have a look at the Resource Monitor, how much FF keeps writing to the disk. It never goes below 100 KB/s, loading a resource-heavy page (which is what unfortunately most of the Internet is now) bursts it up to 5-10 MB/s on load time. Idling with just two tabs open, Facebook and a YouTube video on pause will keep it firmly over 1MB/s 24/7. Left idling like this, it would write ~80GB of data in 24 hours. In my case, Firefox consumes ~98% of all the data written to SSD on a typical day.
Mind you, this is with all the “restore session on crash”, “use disk cache”, etc. options found in about:config disabled. With them on, the usage is even higher than that.
Why it matters
This didn’t mean much in the age of spinning rust (HDD), where the reads/writes do not directly correlate with the longevity. But on SSD’s the story is very different. Every SSD has basically a set amount of “fuel” on it, which is consumed by writes. After the “fuel” is consumed, the SSD fails. A typical consumer-grade SSD with a TBW rating of 180TBW would thus fail in ~5 years of having Firefox idle 24/7. Five years is a long time, sure. But one way to think about is that just Firefox shaves 5 years off the time before a SSD ends up in a landfill.
This combined with the millions of worldwide users means that Firefox alone generates literal tons of SSD e-waste every year because of SSD’s failing earlier than they otherwise would
The culprit is obviously that Firefox was developed in the time of the old paradigm, when RAM was expensive and there was less of it to go around, while HDD’s provided virtually unlimited amount of storage compared to the RAM which (in simplified terms) do not care about at all whether data is being written on them or not. So the choice back then was obvious, use less RAM and more disk.
But now the paradigm has changed: RAM is fast, cheap, and plentiful now. And while the age of solid-state storage (SSD) brought us fast speeds and reliability over random mechanical failures of HDDs, they also presented a new problem: hard limit on the amount of data that can be written to it. And developers are yet to catch up with the new paradigm, including all the major browsers today.
What Firefox development should move towards
While I would like to see the RAM disk bug fixed, that wouldn’t really fix the problem for the general public at large since creating a ram disk and moving the profile folder to it is largely a techie minority solution.
The thing is, the total size of the profile folder isn’t even that large, it’s just that it’s being constantly updated and written to. Making a 1GB ramdisk was enough to keep the whole profile folder in it. So using more RAM instead of disk wouldn’t actually up the RAM usage too much at all.
I do remember the next-gen “browser wars” of the 2000s and the memes of Chrome and Firefox eating up all your RAM, so I understand how we got to this point when the pressure was to decrease RAM usage at the expense of more disk usage. It made perfect sense back then.
And in many cases lower RAM usage is still needed, it’s not like there aren’t a ton of 4GB ram netbooks still out there (and even being sold today).
What I’m saying, is that Firefox should be more smart about it. Automatically adjust the RAM use based on the hardware. There is absolutely no reason a SSD should be trashed on a system when 20GB of free RAM is sitting completely unused.
And if developing an auto-adjusting algorithm to balance the ram/disk usage seems a daunting endeavour for development, it wouldn’t be a bad idea to just chuck everything in RAM and let the OS worry about paging memory to disk. For Windows, Microsoft has worked on this feature for over two decades now and it’s doing its’ job pretty well on systems where limited RAM is available. I guess the question is, “why a software should even worry about when to cache to disk when it’s really the OS’s problem to figure that out”.
Generally speaking, it should be categorized something like this:
Always Save on Disk
Never Save on Disk (when enough RAM is available)
- Media content (especially streaming video)
- Temporary files
Save per user preference
- Session data (“restore session on crash” option)
- Form data
Also the “restore session on crash” could have 3 levels: All / None / Just urls and forms
Because saving the whole session data including all the heavy resources on page seems overkill for most users, taking up hundreds of megabytes of space. While I think most would be fine saving just the urls of opened tabs along with any filled form data, which would take mere kilobytes instead.
And the None option should actually work (it doesn’t now), meaning that if you don’t care about session restoring, absolutely nothing should be saved.
RAM (system memory):
Super fast; Has unlimited reads/writes; does not wear; basically infinite lifetime.
SSD (system storage; solid-state):
Fast; unlimited reads, but finite amount of writes; wears, lifetime is directly correlated with the amount of data written to it (hence the comparison to fuel)
HDD (system storage; spinning disk):
Slow; theoretically unlimited reads and writes and infinite lifetime, but in reality mechanical wear will eventually cause it to randomly fail; reads and writes not directly correlated with lifetime
Let’s use more RAM when it’s available instead of shaving combined millions of hours of SSD life worldwide.
RAM does not mind at all about it. It just makes sense.