While I’m pleased with where we are now, we still have a way to go to get our overhead down even further. You can read more about the background of this project and many of the changes in our initial newsletter and the follow-up. 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.

There have been some big wins, but really it’s the myriad of minor improvements that compounded into a large impact. 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. 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. 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.ĭoubling the number of content processes and not seeing a huge jump is quite impressive. 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. 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.ĭoubling the number of content processes is the logical extension of the e10s-multi project. The goal is to allow us to start spinning up more processes while still maintaining a reasonable memory footprint.

Over the past year, the Fission MemShrink project has been working tirelessly to reduce the memory overhead of Firefox.

Why does firefox open so many processes