This is a continuation of my Are They Slim Yet series. For background see my previous installment.
Firefox’s upcoming release 57 has a huge focus on performance. We’ve quantum-ed all the things but we haven’t really talked about memory usage, which is something that often falls by the wayside in the pursuit of performance. Luckily since we brought AWSY in tree it’s been pretty easy to track memory usage and regressions even on separate development branches. The Stylo team was a big user of this and it shows, we flipped the switch to enable Stylo by default around the 7th and you can see a fairly large regression, but by the 16th it was mostly gone:
Some great work has been happening lately to reduce Stylo's memory usage. https://t.co/TkwPKOQRT2 and https://t.co/C8x59Ur5IC have details.
— Nicholas Nethercote (@nnethercote) September 15, 2017
Hopefully I’ve convinced you we’ve put a lot of work into performance, now let’s see how we’re doing memory-wise compared to other browsers.
The methodology for the test is the same as previous runs: I used the ATSY project to load 30 pages and measure memory usage of the various processes that each browser spawns during that time.
The results
Edge has the highest memory usage on Windows, Chrome comes in with 1.4X the memory usage of Firefox 64-bit on Windows, about 2X Firefox on Linux. On macOS Safari is now by far the worst offender in memory usage, Chrome and Firefox are about even with Firefox memory usage having gone up a fair amount since the last time I measured.
Overall I’m pretty happy with where we’re at, but now that our big performance push is over I’d like to see us focus more on dropping memory usage so we can start pushing up the number of content processes. I’d also like to take a closer look into what’s going on on macOS as that’s been our biggest regression.
Browsers included are Edge 38 on Windows 10, Chrome Beta 62 on all platforms, Firefox Beta 57 on all platforms, and Safari Technology Preview 40 on macOS 10.12.6.
Note: I had to run the test for Safari manually again, they seem to have made some changes that cause all of the pages from my test to be loaded in the same content process.
As someone who often runs a fairly memory constrained OS X machine, Firefox has traditionally been a livesaver – past a couple of tabs, Firefox outperforms Chrome just due to memory starvation. I would love to see this big regression fixed.
That said on my somewhat beefier Macbook, Nightly runs wonderfully.
I definitely want to look into this!
In the meantime, on your older machine you might consider tweaking the
Performancesettings inabout:preferences(at least this is available on Nightly). Uncheck theUse recommended performance settingsbox and you can drop the number of content processes. 2 might be a more reasonable setting for your use case.Yeah, I probably should do this. I can afford to run Nightly as my daily driver so I try to run as close to stock config for bug reporting purposes as possible, but I suspect from that perspective e10s-multi is basically the same no matter how -multi it is.
wow, just wanna thank you guys for incredible work.
now we have the conditions of possibility for firefox to be gaining ground again.
I’m confused. Based on that following chart it looks like the regression wasn’t mostly gone, but all gone and the memory use got better.
Or perhaps it’s just that this chart isn’t enough to show the whole story…
After the 7th the blue dots include Stylo, purple are without so you can see a larger difference. After the 16th we landed a few fixes (some not related to Stylo), so there was an overall large drop and then you can see the difference between blue and purple is much smaller.
How are you measuring memory usage?
Firefox with just 4 content processes takes a couple of hundred MB more in total than 10 Chromium processes with the same tabs open.
This is with 4 content processes, 30 tabs open.
But that’s just completely unfair, much more unfair still than my already unfair comparison…
If I limit Chromium’s “content” processes to also 4 then Firefox uses 150% the memory.
If that scales linearly with more tabs then Firefox could even surpass Safari in your graph…
It’s probably better than before but it’s still bad.
There’s nothing unfair about testing browsers with default options.
That’s a strawman. It’s not the defaults I’m criticizing but the way you compare the browsers using an unfair test.
Try with 1 or 4 or even 8 tabs. Chromium still wins with 4 extra rendering processes.
Or try 100 tabs. I wouldn’t be surprised if Chromium won despite running 8-9 times the number of rendering processes than FF.
So again, it’s an unfair comparison. FF’s “content” processes use much more memory than Chromium’s. That is why you should be talking about when talking about Quantum and Stylo, not some unfair comparison.
Also, FF has to limit the number of content processes so drastically exactly because it is so memory hungry and possibly due to other inefficiencies.
Chromium doesn’t have to, but it’s quite easy to limit it to FF’s low number.
Also, the default limit for Chromium seems to be 35 (?) processes.
So if you don’t want to limit Chromium’s processes to get a fair comparison, try setting Firefox to 35 content processes …
Thanks for this! I’ll be switching from Debian 9 to Ubuntu 18.04 when released and hope to be able to put this through the ropes.
My biggest challenge with Firefox is being able to export the 1000’s of passwords, etc from Chrome so that I have no need to use both.
Great to hear your interested in switching! A password manager would probably help (maybe something like lastpass).
I think you were asking about how I made my graphs elsewhere, I just use Google sheets!
I’m a Firefox user on a mid-2013 Macbook Air (1.3 GHz Intel Core i5, 4 GB 1600 MHz DDR3) running macOS Sierra 10.12.6. I’d been on the beta channel on Firefox in an attempt to get something stable that didn’t constantly leak memory, because prior to that stable had been bad since the move to the first stable version made with Rust. I’d disabled and removed every extension and add-on from Firefox, so it was just Firefox or its internal components that were leaking, even in v56. This morning I went from v56 to v57.0b3 Quantum, and I’m really hoping that this finally will solve the memory problems that forced me to use a different browser as my primary browser for a few years. Prior to that I was an extremely loyal user from the first Netscape to the first Mozilla to the first Firefox all the way until Firefox eventually would just become unusably slow on a regular basis and I’d have to restart it. So, I’m very, very thankful for changes to fix this. However, I still see a lot of leaks reported as bugs in the list, and hope that this list all goes away soon, whether it’s people fixing them or at least verifying that they have been fixed via Quantum: https://bugzilla.mozilla.org/buglist.cgi?quicksearch=leak Thank you again, and I hope that macOS builds along with Windows and Linux can somehow be automated and tested regularly to completely eliminate these leaks in the future.
I don’t expect Quantum to fix any leaks. If you can reproduce please file a bug report with
[MemShrink]in the whiteboard and attach an about:memory report.Unfortunately https://bugzilla.mozilla.org/buglist.cgi?quicksearch=leak is not a great resource, it just shows a ton of old outdated bugs.
Do you have any pointers to articles for getting involved in Firefox memory debugging? A quick DDD search didn’t turn up anything. I’m currently on OSX staring at a nightly with 17 tabs open and nearly 2.5G of resident memory. I would love to help fix this!
Thanks! Filing a bug with steps to reproduce, an about:memory report, and
[MemShrink]in the status whiteboard is usually the starting point. If you have any questions feel free to hop on the #memshrink channel on our IRC server.