A year later let’s see how Firefox fares on Windows, Linux, and OSX with multiple content processes enabled.
Results
We can see that Firefox with four content processes fares better than Chrome on all platforms which is reassuring; Chrome is still about 2X worse on Windows and Linux. Our current plan is to only move up to four content processes, so this is great news.
Two content processes is still better than IE, with four we’re a bit worse. This is pretty impressive given last year we were in the same position with one content process.
Surprisingly on Mac Firefox is better than Safari with two content processes, compared with last year where we used 2X the memory with just one process, now we’re on par with four content processes.
I included Firefox with eight content processes to keep us honest. As you can see we actually do pretty well, but I don’t think it’s realistic to ship with that many nor do we currently plan to. We already have or are adding additional processes such as the plugin process for Flash and the GPU process. These need to be taken into consideration when choosing how many content processes to enable and pushing to eight doesn’t give us much breathing room. Making sure we have measurements now is important; it’s good to know where we can improve.
Overall I feel solid about these numbers, especially considering where we were just a year ago. This bodes well for the e10s-multi project.
Test setup
This is the same setup as last year. I load the first 30 pages of the tp5 page set (a snapshot of Alexa top 100 websites from a few years ago), each in its own tab, with 10 seconds in between loads and 60 seconds of settle time at the end.
Note: There was a minor change to the setup to give each page a unique domain. At least Safari and Chrome are roughly doing process per domain, so just using different ports on localhost was not enough. A simple solution was to modify my /etc/hosts file to add localhost-<1-30> aliases.
Methodology
Measuring multiprocess browser memory usage is tricky. I’ve settled with a somewhat simple formula of:
total_memory = sum_uss(content processes) + sum_rss(parent processes);
Where a parent process is defined as anything that is not a content process (I’ll explain in a moment). Historically there was just one parent process that manages all other processes, this is still somewhat the case but each browser still has other executables they may run in addition to content processes. A content process has a slightly different definition per browser, but is generally “where the pages are loaded” — this is an oversimplification, but it’s good enough for now.
My definitions:
| Browser | Content Definition | Example “parent” |
|---|---|---|
| Firefox | firefox processes launched with the -contentproc command line. |
firefox without the -contentproc command line, plugin-process which is used for Flash, etc. |
| Chrome | chrome processes launched with the --type command line. |
chrome without out the --type command line, nacl_helper, etc. |
| Safari | WebContent processes. |
Safari, SafariServices, SafariHistory, Webkit.Networking, etc. |
| IE | iexplore.exe process launched with the /prefetch command line. |
iexplore without the /prefetch command line. |
| Edge | MicrosoftEdgeCP.exe processes. |
MicrosoftEdge.exe, etc. |
For Firefox this is a reasonable and fair measurement, for other browsers we might be under counting memory by a bit. For example Edge has a parent executable, MicrosoftEdge.exe, and a different content executable, MicrosoftEdgeCP.exe, arguably we should measure the RSS of one the MicrosoftEdgeCP.exe processes, and USS for the rest, so we’re probably under counting. On the other hand we might end up over counting if the parent and content processes are sharing dynamic libraries. In future measurements I may tweak how we sum the memory, but for now I’d rather possibly under count rather then worry about being unfair to other browsers.
Raw numbers
| OS | Browser | Total Memory |
|---|---|---|
| Ubuntu 16.04 LTS | Chrome 54 (see note) | 1,478 MB |
| Ubuntu 16.04 LTS | Firefox 55 – 2 CP | 765 MB |
| Ubuntu 16.04 LTS | Firefox 55 – 4 CP | 817 MB |
| Ubuntu 16.04 LTS | Firefox 55 – 8 CP | 990 MB |
| macOS 10.12.3 | Chrome 59 | 1,365 MB |
| macOS 10.12.3 | Firefox 55 – 2 CP | 1,113 MB |
| macOS 10.12.3 | Firefox 55 – 4 CP | 1,215 MB |
| macOS 10.12.3 | Firefox 55 – 8 CP | 1,399 MB |
| macOS 10.12.3 | Safari 10.2 (see note) | 1,203 MB |
| Windows 10 | Chrome 59 | 1,382 MB |
| Windows 10 | Edge (see note) | N/A |
| Windows 10 | Firefox 55 – 2 CP | 587 MB |
| Windows 10 | Firefox 55 – 4 CP | 839 MB |
| Windows 10 | Firefox 55 – 8 CP | 905 MB |
| Windows 10 | IE 11 | 660 MB |
Browser Version Notes
- Chrome 54 — aka chrome-unstable — was used on Ubuntu 16.04 LTS as that’s the latest branded version available (rather than Chromium)
- Firefox Nightly 55 – 2 CP is Firefox with 2 content processes and one parent process, the default configuration for Nightly.
- Firefox Nightly 55 – 4 CP is Firefox with 4 content processes and one parent process, this is a longer term goal.
- Firefox Nightly 55 – 8 CP is Firefox with 8 content processes and one parent process, this is aspirational, a good sanity check.
- Safari Technology Preview 10.2 release 25 was used on macOS as that’s the latest branded version available (rather than Webkit nightly)
- Edge was disqualified because it seemed to bypass the hosts file and wouldn’t load pages from unique domains. I can do measurements so I might revisit this, but it wouldn’t have been a fair comparison as-is.
On operating systems with memory compression, RSS is pre-compressed size, correct?
I guess we’re talking about zram here, IIRC memory is paged out to zram so it wouldn’t be included in RSS — I used to measure this for our b2g project, it’s just been a while and I don’t recall the details! I’d be happy to hear from someone more authoritative on this.
/me waves to the b2g/Android/ChromeOS folks.
Windows has memory compression, Linux has 2 kinds of memory compression (zram and zswap), and IIRC macOS also has memory compression though I’m not so sure on that one.
Interesting to see the concept expand. I think these are all roughly “ram based pagefiles,” so that memory wouldn’t be included in RSS. In Windows-speak it would still affect the commit charge aka private bytes.
I wish this holds good in the real world too – but everytime I go back to firefox, it crashes, laggs and then again next week I upgrades the nightly, developer version, FF mainstream, tries again and goes back to something else. Looks like I am in a loop that repeats every week for last 5 – 6 years for sure.
I think it will be encouraging to see plugins like ublock origin on various browsers.
Me too! It’s hard to do reliable side-by-side tests on live sites, I plan on doing a write up about what we can do to improve our test coverage of more modern web features.
It’s worth checking you don’t have any add-ons enabled that don’t support multiprocess Firefox.
whenever I find those symptoms it’s for this reason.
Did you trey creating a new profile before launching Firefox ?
Awesome achievement. I’ve came back to Firefox from Chrome 3 years ago and I couldn’t be more happier!
Thank you for your work 🙂
I wonder if Firefox is 32-bit on Windows and 64-bit on MacOS. That would explain the 2x difference in memory usage.
It looks like 64-bit Chrome was used on all platforms.
Would you mind sharing the “about” pages of the browsers on Windows? (chrome://version for Chrome and about://support for Firefox)
I get the desire to compare across operating systems, but I don’t think it’s a particularly useful metric. On the other hand comparing browsers against each other on the same OS certainly makes sense.
Comparing the ratio across operating systems is a littler more interesting, so in this case Firefox did about 2X better on Linux than Chrome, but only a smaller fraction on OSX. I don’t have an answer as to why, but it’s an interesting question.
Either way this was all 64-bit. I put together a gist with the full details.
Instead of running sites “from a few years ago”, how about running recent web pages? Especially considering that the proliferation of bloated client side frameworks is extremely bad for perf/memory usage. I do have a few pages that use up in excess of 30-50M each, such as whatsapp web, slack, google docs, etc.
Also I asked this already a year ago, but how about tests with some popular addons, especially adblockers (last year I mentioned adblock+noscript, but since I have switched to ublock+umatrix) since they need to maintain huge blocklists.
I would also welcome tests that also incorporate the memory usage of the devtools, since I have found those to sometimes lead to skyrocketing memory usage.
I personally use the dead simple method of “measure total system memory usage, close browser, measure again” to get a feeling of how many resources the browser is using, since resources may be allocated elsewhere as well (window manager, gl, etc).
For Ubuntu, why didn’t you grab the Chrome releases directly from Google? They’re kept up to date, including the unstable channel.
Also, this is the first time I’ve heard that Edge (or really any browser on Windows) is able to bypass the hosts file. That’s a little alarming, to be honest. Have you found out any more information on that?
I may have confused the jargon, but I searched for Google Chrome Canary Ubuntu and came to a google.com page telling me it’s not available.
Do you have a link to officially branded
Chromedev builds for Ubuntu? I’m not interested inChromiumfor these tests.No problem, here you go:
https://www.chromium.org/getting-involved/dev-channel
I know this is a Chromium.org page, but if you look at the links under the Linux section you’ll see that they point back to Google for their hosted versions. Canary doesn’t seem to exist, but you should be able to get the dev channel up and running.
Thanks Barry!
Wanted to come back and also share this page:
http://omahaproxy.appspot.com/
This is where Google lists the specific build numbers for all releases. Canary doesn’t exist on Linux, but if you want to get the closest release possible for testing on Linux, this’ll help you narrow down what to grab
Very useful comparison, but I would also like if you’d included numbers for Firefox with electrolysis turned off. This way we could see if the initial 20% overhead claim still holds true or did it get better.
That ship’s pretty much sailed, we have 2 content processes enabled in Nightly by default now. I can probably do a quick follow up comparing Firefox on Linux with e10s disabled and just 1 content process.
I use Firefox a lot on both MacOS and Windows 10. Why there’s so large difference in terms of memory usage between the two? I hope someone will have a theory on that.
My guess is that Chrome and Safari have better OS integration on mac given their WebKit (developed by Apple) roots.
Hi! Awesome work! Firefox just keeps getting better 🙂
Will you update the graphs with the new values for Win10? As was presented here https://bugzilla.mozilla.org/show_bug.cgi?id=1336398
It seems the advantage vs. Chrome is not that big anymore.
Cheers!
Thank you, I’ll update the graph. We still look good for the 4 CP case luckily 🙂