Chromium and Firefox both consume obscene amounts of memory just to do basic things, more or less equally. However that changes when you're working locally using many applications, compilers, several terminals, code editors, and many documentation tabs open in the browser (can't close all docs I need whilst coding)
I've stress tested the machines I use for work and forced the memory available down to a lower limit to see how these two browsers behave under different conditions. Chromium / Chrome doesn't relinquish RAM as efficiently as Firefox does. Firefox uses inordinate amounts of RAM, but it knows better when to free it, and I'm able to use even limited memory configurations under stress tests with many tabs open. Chromium / Chrome just freezes randomly if you have 8 or 10 tabs open whilst doing equivalent work, sometimes to the point of halting the whole system.
For heavy duty work, Firefox just works better.
@h That might be due to Firefox being written largely in Rust, as precise and efficient memory tracking at compile time was the one of the features it was specifically designed for. 🙂
@vertigo That seems to be the case wirh Firefox Quantum, indeed. Although not all of Firefox has been re-implemented. I believe I read months ago that only the CSS engine was rewritten in Rust **and** shipped. It's quite possible that other parts of Firefox have been re-implemented since then as well.
In parallel there's also the Servo browser (being written from scratxh in Rust) which isn't yet very usable at this time, but I'm hopeful it can deliver even better results if it does away with the resourcehognness of current browsers.
@h But if the docs don't work in lynx or dillo, then the docs are bad, yeah?
Agreed. Chrome under stress will just hog the processor, Ff is more decorous.
@h True. i have 16 GB of memory, and I can run both browsers without filling it. The aging processor is my bottleneck.
@h strange; the machine i've used most in the past year has 2GB RAM (shared with the GPU) and no swap, and my experience has been the exact opposite. chromium uses less memory overall, and when it runs away with itself it very rarely locks the machine up. firefox, not so much.
@h having said which, neither worked at all well until i remembered that i had the option of using i386 binaries even on an amd64 lubuntu
also, swap helps a lot, which tells m both browsers have memory leaks
@thamesynne At least a couple other devs have confirmed their experience is consistent with my observations. Then, I believe none of them and neither am I using a 32-bit machine. This is an i7 machine with 8Gb RAM and I tested several memory and swap sizes down to 1Gb RAM.
@thamesynne No significant hiccups felt between 3 Gb and 2Gb. 64-bit i7 and stock Firefox Quantum
@h did you try without any swap at all? on a much slower CPU? on a system where CPU and GPU are fighting over memory? running from a microSD card?
the thing with developers is that they tend to use developer-class machines. my little Alleged Laptop is about as far from that as it's possible to be; but its specifications are very similar to those of a low end chromebook... and on that, chromium is out in front.
this may not be coincidental.
@h also, which OS / distro? which kernel? any VM tuning in that kernel? i ask because linux's overcommit behaviour in the absence of swap seems to be at least partly implicated in the issues i've found; on windows 10 32-bit on a similar spec, my impression is that firefox feels a bit faster than chromium, but that both are acceptably fast and stable... but then windows refuses to run without a swapfile
@thamesynne You are right in that developers tend to use development machines and that my observations are only useful for developers doing heavy duty work, as explicitly stated several times before. Everything else is beyond the scope of my observations.
Sunbeam City is a Libertarian Socialist solarpunk instance. It is ran democratically by a cooperative of like-minded individuals.