▲ 85 points
back
44 comments
Primary reason I switched back from chrome to firefox couple of years ago is for memory usage actually - got really tired of browser eating all my ram (with every extension and tab adding more and more usage).
And no, i rarely actually have enough free ram - it goes to better use.
I hope firefox handles this better than chrome - any fundamental differences between sandboxing of every thread in chrome and what electrolysis is doing?
> any fundamental differences between sandboxing of every thread in chrome and what electrolysis is doing?
"Sandboxing every thread" isn't exactly what Chrome does. Chrome provides a separate process for each browser tab. That, of course, requires more memory (since processes cannot directly share memory).
Firefox, on the other hand, uses a single process for the rendering for all tabs, but this process is separate from the main Firefox process. This means that the browser UI is still responsive even if one of the tabs is not responsive.
Of course, actual profiling may yield different results due to other factors that also affect memory usage, but ceteris paribus, using only two processes for n tabs should consume less memory than using n processes for n tabs.
This is definitely not always the case in my experience, although that might be due to some addon (I have quite a few) hanging the main FF thread/process.
I'd love to see a 'task manager' that can show CPU usage as well as memory use by individual tabs, because occasionally I see CPU use spike (noticed by laptop fans spinning up) and am reduced to closing random tabs in the hope it'll get better.
> This is definitely not always the case in my experience, although that might be due to some addon (I have quite a few) hanging the main FF thread/process.
My experience matches yours.
I think chimeracoder means that's the way Firefox works if e10s is enabled, which wouldn't be true for you unless you've explicitly done so. (I haven't enabled it either)
> any fundamental differences between sandboxing of every thread in chrome and what electrolysis is doing?
Chrome does process-per-tab more or less. Current plans for e10s are to start with just 1 content process and see how that can be increased later.
So basically e10s does not suffer per-process-overhead as chrome does. For now.
Actually, Chrome does process-per-domain. Almost always several tabs of the same domain will share a process. You can check this by killing one process and seeing lots of tabs go away.
No. We currently mostly do process-per-tab, but it gets complicated depending on how exactly a given window/tab was opened and certain resource heuristics. We're moving to process-per-origin[1], largely for the security improvement. But, that's been a huge, multi-year engineering effort that's only now approaching fruition.
[1] https://www.chromium.org/developers/design-documents/site-is...
I see.
So the reason more than one tab will crash when killing a process is that all those processes were sharing a resource of some sort?
Maybe the trick isn't to do process-per-tab or 1 content process and 1 UI process but to instead do some kind of "intelligent" number of content processes based on CPU and tab count? Like if you had 50 tabs on a quad core processor you could have 1 UI process and say five content processes?
Or another idea, have some kind of upper limit of memory a tab can use before it gets its own process.
That's likely what'll happen eventually. But we're starting with 1 content process because even that is a huge change and is going to cause disruption and will take a while to iron out the wrinkles.
I had to disable e10s because whenever I switched tabs the page would sometimes be replaced indefinitely by a white screen with a big loading indicator. Tried it again recently and the problem was still there, but less so.
I get that multi-process is important, but I really hope Mozilla holds off on a wider release until performance and stability are fully ironed out.
Part of the problem is that e10s Firefox by default still uses just one UI process and one "content" process, shared by all tabs. So a web page can't cause the UI to hang, but it can cause all other web pages to hang.
Curious testers can go to about:config and set "dom.ipc.processCount" higher than 1 to increase the number of content processes. I suggest trying this only in Firefox Developer Edition or Nightly, and not in your main browsing profile, since there are still some serious bugs and active development related to this configuration (so consider it a chance to test future improvements, rather than something that’s ready for regular use):
Wow, thanks! I use Firefox Developer Edition, and haven't seen any discernible improvement in performance with e10s, but setting "dom.ipc.processCount" higher than 1 already seems to be making my browser run faster.
When e10 becomes the default, will the number of content processes still default to 1?
It'll be 1 at first. It's likely to then gradually be increased over time, probably to 2, then 4, maybe 8. Not sure about beyond that.
I'm currently working on reducing memory usage to help with this, because that's the main downside of increasing the content process count. There are all sorts of trade-offs here: performance, memory usage, address space usage, security, crash-resilience, and they all tug in different directions.
There's a bug open for basing it on the amount of cores and memory.
Yes, the conclusion of the link says so.
Where? I don't see any such conclusion. Mind quoting the relevant bit?
> Overall we see a 10-20% increase in memory usage for the 1 content process case (which is what we plan on shipping initially).
> I had to disable e10s because whenever I switched tabs the page would sometimes be replaced indefinitely by a white screen with a big loading indicator.
I'm pretty sure I know what loading indicator you're talking about, though I don't have a screenshot handy.
Basically, this is because one of the other tabs is hogging the rendering process. Since the Firefox UI[0] is controlled by a separate process under e10s, it's still responsive while the other process is rendering webpages. So, you're able to switch tabs before there's something there to switch to.
Without e10s, under this situation, the Firefox UI will be unresponsive while the tab is rendering web content (the browser will appear to lock up). That doesn't necessarily mean the tab will always be fully rendered by the time you're able to switch, but the loading indicator was added to e10s specifically because multiprocess mode makes this situation more likely to occur than under single-process mode.
If you want to see what I'm talking about, try visiting an Amazon product page both in an e10s window and in a non-e10s window[1].
[0] Confusingly referred to as the chrome, a name that predates the browser with the same name
[1] Unless they've fixed it recently, there's a longstanding, known "bug" that's caused by Amazon "prefetching" the content of all links on an Amazon product page. This Javascript is included only when the page is loaded in Firefox, and it's rather redundant, because the content is still re-fetched when the link is clicked. Unfortunately, Amazon hasn't fixed this, and I don't think there's much Mozilla can do about it.
Thanks for the explanation.
I could be wrong, but I feel like I experience the white-page-and-loading-icon with e10s enabled much more often than I do UI hangs with it disabled.
If that's really what's happening, though, then the UI could be improved -- otherwise people like me will end up blaming the issue on the e10s update.
For the time being I have also disabled e10s because it does not yet, and I suspect never will, support userContent.css and userChrome.css.
https://bugzilla.mozilla.org/show_bug.cgi?id=1046166
Eventually, I will need to migrate my user styles to a plugin such as Stylish, but I have preferred the minimalism of userContent.css.
However, seeing the mention of a multi-process user interface elsewhere in this thread is tempting me to ditch userContent so I can re-enable e10s with the multi-process UI, at least once the kinks are worked out.
Can you file a bug report? It can't be fixed if Mozilla doesn't know about it.
I've noticed something like this in Chrome on my Mac anytime I switch tabs... If I come back to a tab, it is just a blank white page and I need to refresh to bring the page back up.
I recently did a clean install of El Capitan and the problem persisted.
Is what's happening to me kind of the same thing?
It'd be interesting to see if one could trim down memory consumption by making Firefox use KSM[0] - on Linux, it's only a single madvise(2) call away.
IIUC most of the shared pages would be common when the process is forked, I doubt there would be enough duplicate content created after the fork to be worth it.
That would be interesting. It's not free though, KSM can use considerable CPU time.
Linux Max - 872 MiB
Windows Max - 1,108 MiB
OSX Max - 1,694 MiB
Something Funny is happening with OSX to spike the memory usage to those levels.
I can't wait to use a Servo (and Rust) based multi-process browser with a lean HTML5 UI. We wait for E10s since 2011 or so, and it still defaults to 1 process and is experimental. The whole XPCOM and XUL legacy API cruft do hurt Firefox. Phoenix/Firebird/Firefox originally started as a lean fork of the Mozilla Suite, with a lot of old cruft removed. Nowadays, I wish there would be a new leaner fork, that kisses the old cruft good bye and starts fresh with Servo and TraceMonkey.
Maybe Mozilla should refocus all resources to Servo and Rust... All what people expect from Mozilla is a lean modern fast independent open source browser.
> The whole XPCOM and XUL legacy API cruft do hurt Firefox.
I'd argue the exact opposite - that "cruft" is the reason I still use Firefox. Extensions are so much better because they can truly have native features and have deep access to the browser. From the native look and feel of the LastPass extension of Firefox to basic stuff I need like sidetabs are only possible because of this deep "legacy" API rather than the extremely limited web based APIs everyone's pushing for these days.
Kill XPCOM and XUL and you kill the only reason I still use Firefox.
At least in the current state of things, nothing to say they won't improve the web-style extension APIs at some point but they're really not ready yet in my opinion, they've got a long way to go and leave a lot to be desired.
Unfortunately, any mention of creating a lean UI based on HTML5 creates a huge debate, nee a holy war, in the Firefox community because this is deemed to reduce the ability to extend the Firefox UI through extensions. Please refer to [1] for a protracted argument on why WebExtensions (or similar framework) are a step-back/inferior because they don't allow for extending the Firefox UI the way XUL-based extensions do. There are a number of power-users and vocal community members who believe that Firefox must have XUL-based extensions otherwise it becomes an inferior clone of Chrome (bollocks if you ask me).
[1] http://forums.mozillazine.org/viewtopic.php?f=23&t=2956625
From what I've seen, the current rate of progress on Servo is quite good. Here is a recent demo of what it can now do http://blog.servo.org/2016/01/25/twis-48/. In a few years, it might be able to do everything that other browsers can do.
The servo project also makes it really easy to get involved http://servo.github.io/servo-starters/.
> Phoenix/Firebird/Firefox originally started as a lean fork of the Mozilla Suite, with a lot of old cruft removed. Nowadays, I wish there would be a new leaner fork, that kisses the old cruft good bye and starts fresh with Servo and TraceMonkey.
Let's not forget that Mozilla Suite was a fresh rewrite of Netscape, causing years of delay - and still resulting in lots of cruft. Code without cruft may only survive in laboratory environnments.
I have noticed that the browser becomes more unresponsive with videos in tabs compared to single process Firefox. I enabled it to make my multi window, lots of tabs workflow smoother but it seems to have the opposite effect.
There was a known problem with video performance with e10s, though it was fixed two months ago (now Firefox 45 Dev Edition). The e10s sandbox inadvertently blocked hardware video decoding.
ah, makes sense. I am on 44.0.1 right now. I'll try the dev edition, thanks!
If you try it and run into a problem, do file a bug! Here's a bugzilla template link: https://bugzilla.mozilla.org/enter_bug.cgi?format=__default_...
Which videos does this occur on? The e10s system is new and some plug-ins may not accommodate e10s yet.
It's going to be interesting to see how the people, ignorant about the additional memory overhead required for a multi-process architecture, will respond to this. My guess is that they'll find another single process browser or revert back to the old version after they've thoroughly finished criticizing the new Firefox version for the increased memory bloat.
The relevant question is how well Firefox compares to competitors like Chrome (which uses multiple processes). Even despite this new overhead, it wouldn't be surprising if the numbers were very competitive.
There will be no more single process browsers left.
However RAM is cheap and very useful in general. The more you have the faster your computer seems to run. Obviously if one has already hit the RAM limit of the motherboard and needs more, s/he's out of luck. I had a 4 GB laptop and couldn't expand it anymore. Then I bought one with 16 GB and I can expand it to 32 GB. I looked explicitly for that option, because I was pretty sure that sooner or later 16 GB wouldn't be enough. I rarely hit 12 GB at the moment.
I absolutely agree with you, but that doesn't stop the people complaining about Chrome memory bloat. The same people that consistently complain about Chrome will now have a new browser to complain about.
You're probably right about the attitude, but you can disable this feature pretty easily.
After e10s is released, they should probably make a "low memory" build of Firefox available with this flag flipped.