This should still alleviate some of the stutters and slowdowns you see from FF when the browser has many tabs open. Electrolysis won’t implement multi-process support in a single leap - instead, all pages will exist in one thread, while the UI is spun off to a different thread. Unfortunately, Firefox wasn’t designed to implement each tab as its own independent process, and adding this capability required the team to rearchitect significant chunks of the browser to be compatible with this new approach. One of the downsides is that this requires more memory on a per-tab basis, which is why Chrome has sometimes been criticized for being a RAM hog.įirefox multi-processor implementation (artist’s depiction) The upside to this approach is that a single slow-running tab can’t lock up the entire system, and it allows each tab to be independently sandboxed from the others. In this model, each browser tab is independent from the other. Adding multi-processingĬhrome, Internet Explorer, and Edge have all used multi-process sandboxing for tabs for years. With that foundation in place, the next projects are sandboxing for security, and isolating extensions into their own processes. After that, we’ll be working on support for multiple content processes. We want 100% of our release users to benefit from this massive improvement. Next up we’ll be working to get E10S to the cohorts not eligible in Firefox 48. This is a huge change for Firefox, the largest we’ve ever shipped… As noted earlier, this is just the first phase. Splitting UI from content means that when a web page is devouring your computer’s processor, your tabs and buttons and menus won’t lock up too… Similar to how chemists can use the technique called electrolysis to split water into hydrogen and oxygen, we’re using project Electrolysis to split Firefox into a UI process and a content process.
0 kommentar(er)
