Memory Usage of Firefox with e10s Enabled

> 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.

> 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.

Can you file a bug report? It can't be fixed if Mozilla doesn't know about it.

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):

http://bugzil.la/e10s-multi

> 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.

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?

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.

That would be interesting. It's not free though, KSM can use considerable CPU time.

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.

> 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

> 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.

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/.

Which videos does this occur on? The e10s system is new and some plug-ins may not accommodate e10s yet.

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.

https://bugzilla.mozilla.org/show_bug.cgi?id=1217185

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.

You're probably right about the attitude, but you can disable this feature pretty easily.