Goodbye RAM :) Or better for RAM, since I can now selectively kill and resume processes?
Oh, I see it's not one process per tab. So does anyone know how I can more easily survive on 2GB with many tabs, other than by constantly killing processes?
Oh, I see it's not one process per tab. So does anyone know how I can more easily survive on 2GB with many tabs, other than by constantly killing processes?
Between lazy tab restore and Chrome's process per tab memory overhead, Firefox is currently waaay better than Chrome for those of us coping with RAM Deficit Disorder and O(e^x) tab syndrome; I hope when the Fox gets process-per-tab they don't close that gap.
You could also try one of the BarTab extensions² and Tab Groups³ to only keep the sites you use loaded.
1: https://addons.mozilla.org/en-US/firefox/addon/ublock/
2: https://addons.mozilla.org/en-US/firefox/search/?q=bartab
3: https://support.mozilla.org/en-US/kb/tab-groups-organize-tab...
And given the amount of dev time that's gone into Chrome / Chromium, it doesn't exactly set a good precedent.
Also, you're missing that there are a number of things that have to be duplicated in a multiprocess model that you only need one of in a multithreaded model. For instance: the JS heap, which has a reasonable amount of overhead.
Some things can be shared between processes like they can be between threads, but not everything.
1: https://blog.mozilla.org/nnethercote/category/compartments/
Edit:
A quick, 100% scientific™ test:
Content processes: 50
Sum: 1858.6
Max: 42.72
Average: 37.172
Content processes: 10
Sum: 791.96
Max: 88.96
Average: 79.196
Content processes: 5
Sum: 624.1100000000001
Max: 137.68
Average: 124.82200000000003
Content processes: 1
Sum: 453.89
Max: 453.89
Average: 453.89
var max = 0;
var sum = 0;
var vals = $$('span[id^="Web Content"][id$="explicit"] span.mrValue');
for (let vi = 0; vi < vals.length; vi++) {
let v = parseFloat(vals[vi].textContent);
sum += v;
max = Math.max(max, v);
}
console.log('Content processes:', vals.length);
console.log('Sum:', sum);
console.log('Max:', max);
console.log('Average:', sum/vals.length);
50 processes caused stuttering when scrolling in the tab bar. 10 & 5 processes felt smooth and allowed tab titles of background tabs to load in quickly during startup. 1 process took forever to actually load in the tab titles of background tabs on startup.
Setting changed via: about:config?filter=dom.ipc.processCount
I'm more talking about metadata / caches. There's a fair bit of stuff that can be global with a single process that cannot be with multiple processes. Sometimes you can use shared memory tricks, but not always.
Also: I wasn't aware there was that much of a memory penalty. Yow.
So I'd say that I keep many tabs open for the exact opposite reason. It enhances what I can do, due to the limitations of my brain.
Within a few decades, I expect for the concept of open tabs and bookmarks to merge. We'll be keeping far more tabs open, and flipping between them effortlessly, or scrolling back to that snapshot in time effortlessly.
I imagine closing tabs will be being like closing Emacs buffers. In practice, you practically never have the need to close an Emacs buffer, for anything you might have a small chance of wanting to work on again soon.