Earlier quoted context omitted.
Multiple processes does not necessarily mean increased memory usage. I'm a little surprised at how many misinformed comments there are like this.
The problem is this: Chrome. Which, last time I checked, often ends up with >100MB private working set per 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 r…
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
Based on running the following script on a freshly generated about:memory profile: var max = 0;
var sum = 0;
var vals = $$('span[id^="Web Content"][id$="explicit"] span.mrValue');
for (let vi = 0; vi
This is with ~400 tabs opened but in "unloaded" state. Only 5 pages were actually fully loaded.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