Over the past year, the Fission MemShrink project has been working tirelessly to reduce the memory overhead of Firefox. The goal is to allow us to start spinning up more processes while still maintaining a reasonable memory footprint. I’m happy to announce that we’ve seen the fruits of this labor: as of version 66 we’re doubling the default number of content processes from 4 to 8.
Doubling the number of content processes is the logical extension of the e10s-multi project. Back when that project wrapped up we chose to limit the default number of processes to 4 in order to balance the benefits of multiple content processes — fewer crashes, better site isolation, improved performance when loading multiple pages — with the impact on memory usage for our users.
Our telemetry has looked really good: if we compare beta 59 (roughly when this project started) with beta 66, where we decided to let the increase be shipped to our regular users, we see a virtually unchanged total memory usage for our 25th, median, and 75th percentile and a modest 9% increase for the 95th percentile on Windows 64-bit.
Doubling the number of content processes and not seeing a huge jump is quite impressive. Even on our worst-case-scenario stress test — AWSY which loads 100 pages in 30 tabs, repeated 3 times — we only saw a 6% increase in memory usage when turning on 8 content processes when compared to when we started the project.
This is a huge accomplishment and I’m very proud of the loose-knit team of contributors who have done some phenomenal feats to get us to this point. There have been some big wins, but really it’s the myriad of minor improvements that compounded into a large impact. This has ranged from delay-loading browser JavaScript code until it’s needed (or not at all), to low-level changes to packing C++ data structures more efficiently, to large system-wide changes to how we generate bindings that glue together our JavaScript and C++ code. You can read more about the background of this project and many of the changes in our initial newsletter and the follow-up.
While I’m pleased with where we are now, we still have a way to go to get our overhead down even further. Fear not, for we have a quite a few changes in the pipeline including a fork server to help further reduce memory usage on Linux and macOS, work to share font data between processes, and work to share more CSS data between processes. In addition to reducing overhead we now have a tab unloading feature in Nightly 67 that will proactively unload tabs when it looks like you’re about to run out of memory. So far the results in reducing the number of out-of-memory crashes are looking really good and we’re hoping to get that released to a wider audience in the near future.
Too bad the MemShrink effort doesn’t appear to have yielded any results in 64-bit Firefox under Linux, especially when using WebRender.
I’d suggest taking a look at the last paragraph, we have quite a few large efforts that will have an impact for Linux. WebRender is not officially supported for Linux, but we do have a bug on file tracking its support, please feel free to file bugs including clear steps to reproduce and memory reports if you see bad memory usage. The team will certainly be focusing on memory usage much in the way they did for Windows.
Could you link larger versions of the graphs, the ones you have were resized to the point their captions aren’t legible.
Sure the evolution graph was linked as “total memory usage”: https://mzl.la/2EYSFLz.
The AWSY graph is a little trickier (we changed some testing variables over the year / switched out VMs), this is the view I focused on:
https://treeherder.mozilla.org/perf.html#/graphs?timerange=31536000&series=mozilla-central,1653935,1,4&zoom=1521191106125.6638,1539741987908.8496,600000000,1002434456.928839
Was it tested against old versions, to know about back porting solution?
Yes, 8 content processes has worked in the past, the memory usage won’t be great though.
Thanks for replying.
‘Worst case scenario’ is 30 tabs open? Are you fkidding me? I have had over 200 tabs open from a single site. And if you’re going to use multiple processes for different purposes use multiple exe’s so we don’t have 11 processes called ‘firefox’ which are indistinguishable from the users point of view.
If you really want to improve memory use and speed fix the way data is accessed from the cache which remains horrendous.
Generally speaking, you are an outlier. Our 95 percentile is 15 tabs. Regardless, this is just our stress test that we run on every build to gather metrics. Feel free to measure as you wish.
On Linux we label the content processes as ‘Web Content’ in programs such as top, on Windows 10 they’ll show up in task manager labeled as ‘Background Process’ nested under the parent process, and on macOS we show up as ‘FirefoxCP Web Content’ in Activity Monitor. Please note that having a separate executable could actually impact memory usage if there’s less sharing between processes. If the tools you use are insufficient to differentiate I’d suggest using different tools.
I’m not sure what this has to do with memory usage, can you elaborate?
I can underscore the comment about number of tabs. I normally use about 4 to 8 windows, each easily containing 10 to 15 tabs. I still have to reset the number of content processes to 1 because if I don’t Firefox gulps so much memory my machine will slow down to the point I can not even operate it anymore and have to reboot.
And yes, the row of seemingly identical processes does not help, especially since the in-browser management of tabs and their resource usage is still underdeveloped.
The funny thing is on Firefox mobile I regularly have 100 or so tabs open and it does not feast on my memory, nor does it get slower, and I’m not missing any functionality compared to desktop.
As noted in this blog post I think you’ll find with more recent releases of Firefox enabling multiple content processes has a reduced impact on memory usage, particularly on Windows. If you enjoy the behavior or Firefox mobile, you might like to try out one the tab unloading extensions. Dormancy is one developed by a long-time Mozillian.
I’d also suggest checking about
about:performance, it has a pretty nice interface as far as correlating tabs and memory usage. If there are features you’d like, you can certainly file an enhancement request.I don’t know what changed in FF66 (didn’t find anything relevant in release notes), but I’ve had much improvement in my RAM usage. My “normal” RAM usage is about the same, but several “bad” tabs that would cause memory runaway (one would go up by about 1GB a minute!) up through at least FF64 seem to not do it any more in FF66.
Keep up the good work!
–Henry