“We can learn from the competition,” said Dotzler. “The way they implemented multi-process is RAM-intensive, it can get out of hand. We are learning from them and building an architecture that doesn’t eat all your RAM.”
That's the money quote here. I've been waiting for this for a long time actually. Every browser I've tried except Firefox just basically eats all my RAM and other app performance (e.g. compiling stuff) goes down the toilet.
Then on the other hand FF has not been so snappy and responsive traditionally. So responsive + soft on RAM is the combination I've really been waiting for. Let's hope they can deliver.
Can someone describe what the "architecture that doesn't eat all your RAM" here is? Is it possible that it will inadvertently provide weaker security protections between tabs than the more naive and RAM-intensive architecture?
I'm not a Firefox user, but considering that 95% of the time about half my RAM is going unused (well, Windows uses it for pre-caching random stuff it thinks I might need), I don't mind high memory usage as long as I get a benefit for it.
If it's just inefficient, that's a different story.
I was in the same situation as you and found that in the end Safari fit that bill for me (not sure if it is an option on your platform). Responsiveness is probably somewhere between Chrome and FF, but memory usage has been much better.
Nevertheless, I prefer Chrome's approach. I can just open the process explorer and kill a few of the most memory hungry tabs/tab groups; with Firefox, there's no other solution than killing the whole browser.
The thing is, workstation and laptop RAM is so cheap. If your browser is eating an appreciable chunk of your 16 or 32GB of RAM, you need to close some tabs.
I switched to Firefox from Chrome about 12 months ago. It isn't as good as Chrome, but I was trying to reduce my Google dependencies.
It has been mostly fine (except for an annoying OS-X multi-screen bug where it screws up the sizing).
I was really looking forward to this feature to help close the gap on Chrome performance.
Until August (I think Firefox 48.x), when it became unusable on any site with... something. I'm not entirely sure what triggers it- I don't think it is just video alone. Something make the entire browser lock up entirely for minutes, and sometimes it even runs out of memory and I have to kill it via the OS.
No add-ins (except for Firebug).
Frustratingly, I can't replicate it well enough to be a useful bug report.
I'm this close to switching back. Muscle memory and shortcuts to Firefox is the only thing stopping me.
So.. this will be great, but please make it a workable browser.
I've found Firefox performance to be absolutely awful at work on OS X. I have no issues at all with it at home on Linux, and didn't have any issues in my previous job on OS X either. I'm not sure if it's OS X specific, a change in recent versions, this laptop being underpowered, or the nature of the work I do (a lot of video stuff), but anything JS heavy severely slows down or locks up the browser. And if anything, it's gotten worse over the last few months.
I have to use Chrome for anything video related or JS heavy (monitoring/graphing stuff for the most part), but I'd hate to switch to it for everything. There are too many addons that I rely on in Firefox, on top of my general dislike for Chrome's minimalist UI and standard Google privacy concerns.
I've tried turning on the config option for electrolysis, but it breaks some addons, so that's still a no go for me for now.
Firebug is quite often the culprit in these kinds of things in my experience. I can't live without it so I put up with it; if you're switching from Chrome however, it seems that you'd be better off just using the built-in inspection.
You might want to try Firefox's built-in Web Console. I switched a year or two ago when it was less powerful than Firebug, but notably more stable, and I haven't gone back since.
> except for an annoying OS-X multi-screen bug where it screws up the sizing
Can't argue with you there. At last exiting full-screen video no longer takes the entire browser out of full-screen.
This should come as no surprise. It has always been an epic architectural mistake to use the same single non-reentrant Javascript engine to both render the UI and run JS for webpages in Firefox. This change will finally undo that huge mistake made so very long ago.
Just so that people don't have to do digging in that article. In about:config, set browser.tabs.remote.autostart to true and check about:support for Multiprocess Windows (might need to restart).
For now though you'll have to disable any plugins for it to work which can be a bit of a handicap. But... almost there :).
Please be aware that if you force-enable e10s while using incompatible addons, you'll end up with a very slow browsing experience. http://arewee10syet.com/ has a compatibility list for some of the most popular addons.
Every odd browser performance topic is dominated by people claiming Firefox has been faster and more scalable than Chrome for years. Every even one is dominated by people claiming the opposite.
This thread seems to be the latter, my experience is the former. If you see bad performance/memory usage with a small number of tabs, are you sure that it's not due to bad plugins?
I think about:memory and about:performance could be helpful. I seem to recall they used to have some reporting on known problem plugins (perhaps as part of https://www.mozilla.org/en-GB/plugincheck/).
Does anybody know more about how Mozilla manages experiments? I'd always assumed that all users downloaded an identical binary and got the same behavior. How do they assign 10% of their users to an experimental group?
Is it possible that two users will see different functionality when they are both using the same OS and release, say Firefox from the latest version of Ubuntu?
We have several different mechanisms for running experiments. The e10s one specifically runs through what we rather poorly named a "system add-on".
e10s code is present in all builds. The system add-on contains logic that decides whether to turn it on or not. The system add-on can be updated daily (or more often), in all channels.
* I apologize for the naming, this is entirely my fault. I spent a lot of the last twelve months scheming/designing and developing experimental update mechanisms for Firefox.
Firefox generates a random number on first run. Users who are selected for the experiment are sent a signed extension from Mozilla that makes browser.tabs.remote.autostart preference return true if they are on the correct release of Firefox.
As with most native A/B tests, the binary probably ships with code for both functionalities. When the browser launches for the first time they generate a random number, and if it's below a certain threshold you get variant A, above you get variant B. The information gets persisted on disk so it remains unchanged across sessions.
Its incredible multi-process took this long. Just goes to show you that your architecture decisions last a long time and are often difficult to change. Chrome had this from day one and never had a big and old codebase to worry about. Yet it took Firefox many years to get multi-process going and my understanding is that its much more limited and simpler than what Chrome or Edge do.
I'm also a little surprised there hasn't been an attempt to launch a completely new Firefox from the ground up. Regardless of what they're doing right now, its still a legacy code monster and much more laggy than the competition. Maybe this is Servo's ultimate purpose, but every Firefox advance is welcomed but always feels like another layer of lipstick on this pig.
Disclaimer: I use Firefox as my main 'non-work' browser several hours a day. Its good, but its very obvious when I'm not in Chrome from a performance/stability perspective.
|| I'm also a little surprised there hasn't been an attempt to launch a completely new Firefox from the ground up.
I (hopefully) think this is what Servo is and will end up being.
Has no legacy code, and is tiny in comparison to Gecko. It's OS support is fairly modern, and has no interest in supporting Windows XP.
It's also written in such a way that allows them to be more multi-threaded and more concurrent than traditional rendering engines.
At some point you have to draw a line in the sand and start again, and I hope Servo is that.
Addons are a big part of the firefox ecosystem and they reach deep into the internals of the browser. So just replacing the browser wholesale would break a lot of things over the course of a single release.
> I'm also a little surprised there hasn't been an attempt to launch a completely new Firefox from the ground up.
It's interesting how the history goes.
We had Netscape 4, and it was crap (remember when resizing a window reloaded the whole page?)
So they was a ground-up rewrite of the rendering engine, resulting in Gecko, which was put in Mozilla.
Gecko was great but Mozilla was a bloaty amalgamation of features, so this was created a pared-down Gecko version called...
~Phoenix~ ~Firebird~ Firefox, which had the great rendering engine and a lean, native-like UI.
Then there was KHTML/KJS which was built for KDE, which had a lean architecture but didn't have the investment to get the compatibility 100% there...
Which Apple then poured into the project in their fork to WebKit, which paid off in spades on the resource-limited iPhone a couple years later.
But Safari was only on the Mac (aside from their "Cocoa on Windows" version and a few open source ports), which Google took as a reason to create...
Google Chrome, where the biggest innovation was rendering each page in its own process (since Safari could freeze up due to one page going in an infinite loop in JavaScript).
So will someone out-Firefox Firefox and do what Chrome was to Safari for multi-processing? Take the rendering engine and put a new chrome on top of it?
> Its incredible multi-process took this long. Just goes to show you that your architecture decisions last a long time and are often difficult to change
At last, you'll be able to view other pages while Facebook's Javascript is in an infinite loop.
With thousands of MIPS and a gigabyte of memory on the job, it had better be responsive. It's pathetic how much compute power it takes to run a browser. Even when the pages aren't doing anything interesting. It's not like they're running a 3D game or something.
I've got 732 tabs open at the moment and performance is still fine. The upper limit for my machine seems to be about 745 ish - much beyond that and FF runs out of video memory or something (new tabs render sites half black).
Why? Except because of memory allocation serialization impact, there is no reason for a multithreaded process being slower than multiprocess. And if that's the cause, it could be solved using multiple heaps.
My guess is that the multithreaded-only design wasn't as good at exploiting the inherent per-tab parallelism. The original architecture probably had some synchronization points (perhaps related to the common GUI code) that did not allow processing each tab truly independently. Regarding memory allocation, yes, in theory one should be able to try to avoid sharing data across threads, which should eliminate serialization on memory allocation and deallocation. But I can easily imagine that in practice, in a codebase that was not explicitly designed to process each tab in parallel, you'll still end up sometimes sharing data across threads.
I imagine they could have instead changed the architecture to be multithreaded in such a way to avoid my imagined sequential bottlenecks, but performance is not the only goal in a multprocess architecture. Sandboxing is another design goal, and that cannot be fully achieved with a multithreaded design.
This is all speculation on my part, so if anyone who actually works on the Firefox codebase could correct me, that would be very welcomed.
The current setup is not multithreaded in the relevant ways.
So the real decision point was whether to take an existing large C++ codebase and try to safely make it multithreaded or to take that same existing codebase, run it in separate processes, and make the communication work.
The latter is actually a simpler engineering task, in my opinion, and paves the way for doing things like sandboxing and whatnot once the initial rollout is complete.
One near-future goal is to move the compositor out from the UI process into its own separate one. Mozilla currently maintains a sizeable blacklist of {feature, GPU, OS, driver} for hardware acceleration because glitchy drivers cause whole-process crashes. When this occurs a separate compositor process can be restarted instantly without the user noticing.
I'd guess that it wasn't the effect of switching from threads to processes that made the difference. It might come from code clean up and fixing some of the IPC that was going on. This would have probably seen many eyes in the firefox dev community so they might have made some efforts to clean up the code under the hood before closing the lid on it.
But I might be wrong as I have no ties to the development process of this.
I'm surprised by the responsiveness claims because my ancient Windows PC runs FF superbly. I think Win10+FF is already more responsive now than it has ever been.
I am also using Ghostery, however, with virtually everything blocked. It wasn't my intent to block ads, but that's mostly how it works out.
It depends on operating system. For instance on OSX Yosemite Firefox is sluggish, yet on Windows 10 it's fast.
People should really mention what operating system they're running when they say "x is slow"
This will probably have significant implications for web worker behavior.
If memory serves, workers are unable to directly communicate with each other in Firefox when the UI thread is blocked, because message handling runs on the same process as the UI thread. Chrome doesn't have that limitation since it's already a multi-process architecture.
Ah, so because I use addons I might not be seeing these benefits for some time? Good to know.
Chrome is right now way faster for me, but I prefer using FF so I am in the Mozilla camp right now. Eager to see this rolled out. Early versions of e10s were very fragile and not so usable for me, so I switched it off.
I use quite a few add-ons and my e10 was disabled because of them. I force enabled e10 using Mozilla's guide https://wiki.mozilla.org/Electrolysis#Force_Enable and didn't notice anything breaking (yet).
I use both FF and Chrome. Chrome is more heavy-duty, so I use it for Dedicated Browsing. I've set it such that when something calls me away and I close Chrome, the tabs will reopen so I can continue where I left off. But sometimes I'll be doing something in another program and need to look up something quickly. In such cases, I don't wanna wait while Chrome reopens 11 tabs so I'll use FF instead. My FF-tabs aren't saved between sessions, so I only see a single fresh tab when I open it.
I don't know. "Eating up all my ram" seems perfectly acceptable to me at first glance. I purchase ram and use it in my computer for expressly this purpose: to improve the responsiveness and snappiness of programs.
Where do you draw the line at what's acceptable use of ram and what's not? I have 32G on my desktop, is it unacceptable that chrome is using 8G?
[+] [-] rsp1984|9 years ago|reply
That's the money quote here. I've been waiting for this for a long time actually. Every browser I've tried except Firefox just basically eats all my RAM and other app performance (e.g. compiling stuff) goes down the toilet.
Then on the other hand FF has not been so snappy and responsive traditionally. So responsive + soft on RAM is the combination I've really been waiting for. Let's hope they can deliver.
[+] [-] toxican|9 years ago|reply
[+] [-] schoen|9 years ago|reply
[+] [-] hokkos|9 years ago|reply
[+] [-] blakeyrat|9 years ago|reply
If it's just inefficient, that's a different story.
[+] [-] Angostura|9 years ago|reply
[+] [-] kohanz|9 years ago|reply
[+] [-] tomp|9 years ago|reply
Can't wait for this fix!
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] chakalakasp|9 years ago|reply
[+] [-] nl|9 years ago|reply
It has been mostly fine (except for an annoying OS-X multi-screen bug where it screws up the sizing).
I was really looking forward to this feature to help close the gap on Chrome performance.
Until August (I think Firefox 48.x), when it became unusable on any site with... something. I'm not entirely sure what triggers it- I don't think it is just video alone. Something make the entire browser lock up entirely for minutes, and sometimes it even runs out of memory and I have to kill it via the OS.
No add-ins (except for Firebug).
Frustratingly, I can't replicate it well enough to be a useful bug report.
I'm this close to switching back. Muscle memory and shortcuts to Firefox is the only thing stopping me.
So.. this will be great, but please make it a workable browser.
[+] [-] wjoe|9 years ago|reply
I have to use Chrome for anything video related or JS heavy (monitoring/graphing stuff for the most part), but I'd hate to switch to it for everything. There are too many addons that I rely on in Firefox, on top of my general dislike for Chrome's minimalist UI and standard Google privacy concerns.
I've tried turning on the config option for electrolysis, but it breaks some addons, so that's still a no go for me for now.
[+] [-] mnarayan01|9 years ago|reply
[+] [-] nfriedly|9 years ago|reply
You might want to try Firefox's built-in Web Console. I switched a year or two ago when it was less powerful than Firebug, but notably more stable, and I haven't gone back since.
> except for an annoying OS-X multi-screen bug where it screws up the sizing
Can't argue with you there. At last exiting full-screen video no longer takes the entire browser out of full-screen.
[+] [-] uuoc|9 years ago|reply
[+] [-] gnicholas|9 years ago|reply
[+] [-] daenney|9 years ago|reply
For now though you'll have to disable any plugins for it to work which can be a bit of a handicap. But... almost there :).
[+] [-] mintplant|9 years ago|reply
[+] [-] sambe|9 years ago|reply
This thread seems to be the latter, my experience is the former. If you see bad performance/memory usage with a small number of tabs, are you sure that it's not due to bad plugins?
I think about:memory and about:performance could be helpful. I seem to recall they used to have some reporting on known problem plugins (perhaps as part of https://www.mozilla.org/en-GB/plugincheck/).
[+] [-] danblick|9 years ago|reply
Is it possible that two users will see different functionality when they are both using the same OS and release, say Firefox from the latest version of Ubuntu?
[+] [-] lxt|9 years ago|reply
e10s code is present in all builds. The system add-on contains logic that decides whether to turn it on or not. The system add-on can be updated daily (or more often), in all channels.
* I apologize for the naming, this is entirely my fault. I spent a lot of the last twelve months scheming/designing and developing experimental update mechanisms for Firefox.
[+] [-] kbrosnan|9 years ago|reply
https://wiki.mozilla.org/Electrolysis/Experiments
[+] [-] TheCoreh|9 years ago|reply
[+] [-] sp332|9 years ago|reply
[+] [-] drzaiusapelord|9 years ago|reply
I'm also a little surprised there hasn't been an attempt to launch a completely new Firefox from the ground up. Regardless of what they're doing right now, its still a legacy code monster and much more laggy than the competition. Maybe this is Servo's ultimate purpose, but every Firefox advance is welcomed but always feels like another layer of lipstick on this pig.
Disclaimer: I use Firefox as my main 'non-work' browser several hours a day. Its good, but its very obvious when I'm not in Chrome from a performance/stability perspective.
[+] [-] jayflux|9 years ago|reply
I (hopefully) think this is what Servo is and will end up being. Has no legacy code, and is tiny in comparison to Gecko. It's OS support is fairly modern, and has no interest in supporting Windows XP. It's also written in such a way that allows them to be more multi-threaded and more concurrent than traditional rendering engines.
At some point you have to draw a line in the sand and start again, and I hope Servo is that.
You can check out https://github.com/browserhtml/browserhtml which is servo running standalone
[+] [-] the8472|9 years ago|reply
[+] [-] kalleboo|9 years ago|reply
It's interesting how the history goes.
We had Netscape 4, and it was crap (remember when resizing a window reloaded the whole page?)
So they was a ground-up rewrite of the rendering engine, resulting in Gecko, which was put in Mozilla.
Gecko was great but Mozilla was a bloaty amalgamation of features, so this was created a pared-down Gecko version called...
~Phoenix~ ~Firebird~ Firefox, which had the great rendering engine and a lean, native-like UI.
Then there was KHTML/KJS which was built for KDE, which had a lean architecture but didn't have the investment to get the compatibility 100% there...
Which Apple then poured into the project in their fork to WebKit, which paid off in spades on the resource-limited iPhone a couple years later.
But Safari was only on the Mac (aside from their "Cocoa on Windows" version and a few open source ports), which Google took as a reason to create...
Google Chrome, where the biggest innovation was rendering each page in its own process (since Safari could freeze up due to one page going in an infinite loop in JavaScript).
So will someone out-Firefox Firefox and do what Chrome was to Safari for multi-processing? Take the rendering engine and put a new chrome on top of it?
[+] [-] williadc|9 years ago|reply
Check out Servo: https://servo.org/
[+] [-] stcredzero|9 years ago|reply
The same happened with the original Mac OS!
[+] [-] Animats|9 years ago|reply
With thousands of MIPS and a gigabyte of memory on the job, it had better be responsive. It's pathetic how much compute power it takes to run a browser. Even when the pages aren't doing anything interesting. It's not like they're running a 3D game or something.
[+] [-] corford|9 years ago|reply
[+] [-] faragon|9 years ago|reply
[+] [-] scott_s|9 years ago|reply
I imagine they could have instead changed the architecture to be multithreaded in such a way to avoid my imagined sequential bottlenecks, but performance is not the only goal in a multprocess architecture. Sandboxing is another design goal, and that cannot be fully achieved with a multithreaded design.
This is all speculation on my part, so if anyone who actually works on the Firefox codebase could correct me, that would be very welcomed.
[+] [-] bzbarsky|9 years ago|reply
So the real decision point was whether to take an existing large C++ codebase and try to safely make it multithreaded or to take that same existing codebase, run it in separate processes, and make the communication work.
The latter is actually a simpler engineering task, in my opinion, and paves the way for doing things like sandboxing and whatnot once the initial rollout is complete.
[+] [-] mintplant|9 years ago|reply
[+] [-] gravypod|9 years ago|reply
But I might be wrong as I have no ties to the development process of this.
[+] [-] Lagged2Death|9 years ago|reply
I am also using Ghostery, however, with virtually everything blocked. It wasn't my intent to block ads, but that's mostly how it works out.
[+] [-] jayflux|9 years ago|reply
[+] [-] Zekio|9 years ago|reply
[+] [-] rl3|9 years ago|reply
If memory serves, workers are unable to directly communicate with each other in Firefox when the UI thread is blocked, because message handling runs on the same process as the UI thread. Chrome doesn't have that limitation since it's already a multi-process architecture.
[+] [-] nchelluri|9 years ago|reply
Chrome is right now way faster for me, but I prefer using FF so I am in the Mozilla camp right now. Eager to see this rolled out. Early versions of e10s were very fragile and not so usable for me, so I switched it off.
[+] [-] semicolon_storm|9 years ago|reply
[+] [-] wcummings|9 years ago|reply
[+] [-] Double_Cast|9 years ago|reply
[+] [-] eberkund|9 years ago|reply
[+] [-] matt_wulfeck|9 years ago|reply
Where do you draw the line at what's acceptable use of ram and what's not? I have 32G on my desktop, is it unacceptable that chrome is using 8G?
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] malnourish|9 years ago|reply