How Firefox and Chrome use Process and Threads.
If you’ve experienced high memory usage in Task Manager while running Google Chrome.Surely, you may have been surprised to see that the number of chrome.exe entries radically exceeded the number of actual Chrome windows you had open. What’s the deal with all those processes?
So, Let’s dive deep into the web browser architecture and find out that how browsers use threads and process.In this article we use Google Chrome web browser and Mozilla Firefox web browser as models.
First Let’s see about the Google Chrome Architecture.Chrome has a multi-process architecture and each process is heavily multi-threaded. There main goal is to keep the main thread (“UI” thread in the browser process) and IO thread (each process’ thread for handling IPC) responsive. That implies that offloading any blocking I/O or other expensive operations to other threads.
In this architecture they use separate processes for browser tabs to protect the overall application from bugs in the rendering engine. And also,They have restricted access from each rendering engine process to others and to the rest of the system. This approach brings to web browsing the benefits that memory protection and access control brought to operating systems.
Every chrome process have a main thread and an i/o thread and a few more special-purpose thread and a pool of general-purpose threads.
The “browser process” means that the main process runs the UI and manages tab and plugins.As well as the the tab--specific processes are called as “render process’'. These render process use the “Blink” open--source layout engine for interpreting and laying out HTML.
In the I/O thread, browser process handles handles IPCs and network requests and the render process handles only IPCs.
Then We can refer about the Mozilla Firefox Web browser Architecture . Chrome has used multi-process architecture for years. The advantage of this approach is that a single slow-running tab can’t lock up the entire system, and it allows each tab to be independently run from the others. One of the disadvantage is that this requires more memory on a per-tab basis.
So, in Firefox 48 (Electrolysis Implementation) update,they didn’t implement each tab as its own independent process, and adding this capability required the team to re-architect significant chunks of the browser to be compatible with this new approach. Electrolysis won’t implement multi-process support in a single leap instead, all pages will exist in one thread, while the UI is in another different thread. This process causes slowdowns when the browser has many tabs open.
The after that , Firefox 54 which also supported to the multi-threading. Now the both Chrome and Firefox browsers are supporting to multi-threading and have the power of it.But the case is, Chrome creates a separate content process for each instance of a site that you visit. As an example chrome Opens 10 different tabs with 10 sites and create 10 different processes. Each of those processes consume its own memory with their own instance of the browser’s engine. One open tab in Chrome typically consumes huge amount of RAM.I think you have that experience definitely.
In Firefox 54 approach, The different result compare to chrome is Firefox using less memory than Chrome.In there,Firefox now creates up to 4 separate processes for web page content. So, If you create 4 tabs first, each use those 4 processes, and the additional tabs run using threads within the previous created 4 tabs. Multiple tabs within a process share the browser engine that already exists in memory, instead of each creating their own.And It causes to low consumption of the memory than chrome.
Then after that they released Firefox Quantum also features a ideal multi-process architecture that well balances speed with memory consumption. That means Firefox Quantum often loads pages faster than Chrome, while typically using less RAM. With Firefox, users can open numerous tabs, while still having enough RAM left to run other heavy applications.
