‘Just Right’ Multi-Process Architecture Helps Firefox 54 Claim Memory Usage Crown

Firefox 54 launched with a more advanced multi-process architecture than the one we saw implemented in Firefox 48 last year. The improved architecture raises the number of processes enabled by default from two to five, which Mozilla argues is a “just right” compromise between low memory usage on one side and performance and security on the other.

Firefox’s Electrolysis Architecture

Mozilla started work on the multi-process Electrolysis architecture more than eight years ago after it saw the advantages it can bring to a browser. Chrome implemented its multi-process architecture from day one, which could be seen as foresight by Google’s engineers, who saw that this type of architecture would be needed to protect users in the future. It was also a benefit of making a new browser from scratch.

Ryan Pollock, Mozilla’s Senior Product Marketing Manager, admitted that the organization wasn’t willing to switch too aggressively to Electrolysis because it knew it would break the add-ons that made Firefox so popular in its early days. Mozilla may have changed its mind when it saw that advanced add-ons that could modify the browser’s core weren’t needed, as proven by the popularity of Chrome’s simpler extension model.

The organization recently announced that it has embraced the “WebExtensions” API, which will allow for Chrome-like extensions to work in Firefox with little changes. Mozilla also hopes that this will lead to the creation of a new “Browser Extension” specification that will be adopted by all browser vendors.

Switching to a simpler extension model allows Firefox to enable multiple processes and also isolate them in sandboxes. Mozilla previously enabled only two processes, one for the UI and one for content, last year, in Firefox 48. This ensured that the browser wouldn’t hang as much due to web pages affecting the performance of the browser interface. It also brought partial sandboxing by keeping the content isolated from the browser (as much as possible).

Mozilla is now taking it to the next level by implementing one process for the browser interface and four for content. Why four? The organization believes that this is the “just right” amount of processes to have for the majority of users, and also in terms of optimizing memory usage.

The more sandboxed the content is, the less sharing happens between multiple tabs. With a rise in the number of used browser tabs, the memory usage also increases significantly, as “redundant” code is added to each process and sandbox. This is why after four content processes are filled with browser tabs or extensions, Firefox will begin to include multiple tabs in the same process.

Mozilla’s Memory Usage Benchmarks

Mozilla ran its own memory usage benchmarks, which showed significant memory usage reduction compared to Chrome:

Windows 10 — Chrome used 1.77X memory as Firefox (64-bit), and 2.44X as Firefox (32-bit)macOS — Chrome used 1.36X memory as Firefox (64-bit)Linux — Chrome used 1.42X memory as Firefox (64-bit)

Firefox 54 is not only more efficient than Chrome, but also all the other major browsers, too:

This drastic reduction in memory usage may not come without significant drawbacks, at least in terms of security. The end results will remain to be seen in future Pwn2Own contests, as well as through the availability of exploits found against Firefox in the wild. If Firefox’s five processes can be 99% as effective in stopping attacks as Chrome’s “one process per tab” architecture is, then Mozilla may have made the right compromise here.

The good news is that the architecture doesn’t seem to be stuck on five processes-only, because Firefox users can also customize the number of processes to be used in the browser. You can enter about:config in your address bar and then change the number in dom.ipc.processCount.

If you know how many tabs you typically keep open and how many extensions you’ve installed, then you can set that number as the number of processes to be enabled. Pollock said that this feature will be available in the browser’s main settings in a future release, which should make it a little more accessible for all users.

Revamping Firefox For Performance And Security

Over the past couple of years or so, Mozilla seems to have accelerated its plans to revamp Firefox, particularly in terms of performance and security. These actions came not a moment too soon, because Firefox has already lost significant market share in recent years because of Chrome, which many have considered a faster and more secure browser.

It’s yet to be seen whether or not Firefox’s “just right” multi-process architecture can bring the browser close enough to Chrome’s security and performance for the differences to be negligible. However, Mozilla has only just begun to improve Firefox’s performance and security.

"Project Quantum" will be implemented soon in Firefox, which will replace core parts of the rendering engine with code written in Rust, a fast memory-safe language that promises to do away with memory corruption bugs. The experimental browser rendering engine, called Servo, that Mozilla has written in Rust, can take advantage of all threads in a CPU to process the elements of a page.

Servo vs Gecko rendering time. Lower is better

The benefits of the Rust language coupled with the modern architectures that Mozilla plans to implement in its browser may allow Firefox to eventually surpass Chrome (its biggest rival) in both performance and security in the not too distant future. Once achieved, these advantages may not be easily matched by Chrome, unless Google also decides to rewrite parts of its browser in Rust or a similar fast and memory-safe programming language.

Lucian Armasu
Lucian Armasu is a Contributing Writer for Tom's Hardware US. He covers software news and the issues surrounding privacy and security.
  • cryoburner
    19816226 said:
    These actions came not a moment too soon, because Firefox has already lost significant market share in recent years because of Chrome, which many have considered a faster and more secure browser.
    People don't use Chrome because it is "faster and more secure". People use Chrome because Google constantly advertises the browser as being "faster and more secure". And when it comes to advertising, there's simply no way Firefox can compete with one of the largest advertising companies on the Internet. Google has a large number of popular "free" ad-supported services, and has made sure to regularly remind users visiting these sites with other browsers that they could click a button to get Chrome for a "faster way to browse the web" or a "better browsing experience". They also install the browser by default with their desktop software and many unrelated freeware apps, leading many to replace their existing browser unintentionally.

    Other browser companies feel that by simply copying Chrome, they will regain users, but in reality, the people still using their browser are mainly using them for the things that make them different. By stripping out these unique features, they'll only lose more users. Opera also tried to make their browser more like Chrome, then eventually just decided to discontinue their browser and tack the Opera brand onto a Chromium reskin. Firefox seems to be headed in the same direction.
  • mikeynavy1976
    Well I've tried 54 and 55 Beta (both 64-bit) and am not seeing much savings compared to Chrome. Only real difference I've seen is that new 55 Beta seems to open a little faster and now is showing addons with "Legacy" tags to them...presumably in preparation for Firefox's new extensions. I'll be curious when developers release the popular ones. I'll probably stick with Chrome as a main browser though. Does anyone know if/when Opera will release a 64-bit browser again...if they haven't already? The last one I see when searching is when it was version 12.
  • randomizer
    Hopefully having multiple processes will permit reclaiming memory more effectively. In my experience Firefox has been traditionally poor in this area. Closing all but one tab should cut memory usage significantly, but it may still chew over 1.5GB if it hasn't been restarted for a while. Being able to kill a content process that has been alive for a long time should help.