Doubling the Number of Content Processes in Firefox

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.

9 thoughts on “Doubling the Number of Content Processes in Firefox”

  1. Too bad the MemShrink effort doesn’t appear to have yielded any results in 64-bit Firefox under Linux, especially when using WebRender.

    1. 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.

  2. Could you link larger versions of the graphs, the ones you have were resized to the point their captions aren’t legible.

  3. ‘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.

    1. ‘Worst case scenario’ is 30 tabs open? I have had over 200 tabs open from a single site.

      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.

      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.

      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.

      If you really want to improve memory use and speed fix the way data is accessed from the cache which remains horrendous.

      I’m not sure what this has to do with memory usage, can you elaborate?

Leave a Reply

Your email address will not be published. Required fields are marked *