e10s / Electrolysis

[megaman]

Another response from my friend the FF user (much of this stuff is technically way beyond my pay grade, hope it adds something to the discussion) -

All I know is that since those changes in both browsers, I can load as many tabs as I want without issue, a problematic tab doesn't slow or crash any of the other tabs, and resource usage has gone way down because tabs can be loaded and unloaded from memory so inactive tabs are unloaded until needed. I've personally found it to be a game changer for me.

Your friend needs to stop using you as the middle-man and talk to us, in-person.
Sandboxing being added to the browser is questionable. It's like throwing in media playability, which a media player normally does, but for sandboxing. Just keep throwing more stuff to the browser and bloating even more. (Now, I am for security, so I will keep thinking about it when others reply.)

I agree with the loading/unloading, plus the Tab Isolation that prevents the whole browser to crash only because of one site. Yet, when Flash crashed, it affected all tabs, even when I tried Chromium-based, and that's when I was curious on how Chromium worked.

No comment on the Plugins and APIs thing, not my alley to discuss.

Chrome = Anything to gather more data from the user to use for ads and generate revenue, that's all I keep hearing. XD

[Axiomatic]

Another response from my friend the FF user (much of this stuff is technically way beyond my pay grade, hope it adds something to the discussion) -

I will address your friend from more of an analytical side, rather then the appeal to authority. (E.g. because Google did, etc.)

Signing and sandboxing is pretty much de facto for all web and mobile apps, and now all browser plugins for both Chrome and Mozilla, but the PM author seems confident that PM has achieved security without implementing those. I don't know enough about his implementation to judge one way or another.

1. As far as I know signing is only a Firefox thing. (You can add unsigned extensions to Chrome last time I checked.)

Since Chrome and Firefox are both implementing tab isolation and sandboxing, and neither has the problems he describes, I think it is safe to assume that their respective engineers wouldn't move forward with those solutions if they were fundamentally broken and didn't offer significant advantages to those browsers. These changes have been a lot of work to implement, and I don't see why they would have dedicated the resources to reworking the core of their browsers if they didn't feel it to be well worth the investment. Why would the entire rest of the industry be moving in a direction that didn't offer any advantages AND made things worse - something doesn't sit right with that idea.

2. The usage of sandboxing for security is partially amusing. The sandbox is only as safe as it is, and does not provide fool proof safety. Circumventions to sandboxing software is common, for instance look at Java, it runs in a native sandbox however exploits are found early early release that lets code be elevated out of the sandbox. The same idea applies to the sandbox of Chrome, humans are not machines inevitably we will err, so learn good browsing skill habits. I would argue it offers significance to the fad culture of security, sandboxing has too few advantages to beat the negatives. (Not saying sandboxing is a failed idea, with proper implementation it can be great (for certain programs), but the limitations it would impose are not worth it, as security can be achieved in different routes.)

All I know is that since those changes in both browsers, I can load as many tabs as I want without issue, a problematic tab doesn't slow or crash any of the other tabs, and resource usage has gone way down because tabs can be loaded and unloaded from memory so inactive tabs are unloaded until needed. I've personally found it to be a game changer for me.

3. If a single tab crashes in Firefox, all tabs crash. The implementation compared to Chrome is different. The thing you also need to understand is unloading tabs is painful to the work flow on slower machines, and you unload a tab from memory you are generally writing it to disk, the disk is substantially read slower than RAM. (You are also unloading more often because less resources are available.)

Also, the new plugin frameworks/api's that both Chrome and Firefox now use, keep the plugins from accessing data that they shouldn't Their access permissions can be granular and revoked, and they cannot access each other. Finally, you can say this plugin can access my bookmarks or not, my browser history or not, my saved passwords or not.

4. You mean the new extension API that Firefox will implement, and has not yet? As far as I know there is no way to turn of certain permissions of an extension in Chrome either. All it does is notify the used permissions of an extension. (This would actually be neat to implement. XUL/XPCOM needs more development nurturing.)

I personally am on board with the huge changes that the two major browsers are making under the hood, and think they are long overdue and offer significant benefits, but I respect other users' rights to choose alternative ideas/solutions.

5. Freedom exist, choose what you want. I think there is more harm being done for one major browser, that being Firefox. Nothing major has been going on for Chromium.

[Supernova]

The friend in a large part say "the big players did so, and they wouldn't have if it was bad, so it's good". That's short-sighted. At most may we bet it's good for them ; we can surely not deduce it's good for the users.

This would actually be neat to implement. XUL/XPCOM needs more development nurturing.)

Yep this "know what the addons may access" sounds like something fine, for the long term.

[LimboSlam]

So could e10s (multi-process) be part of the reason why Firefox consumes so much system resources (battery life), and that's why the current bugs they are fixing is so important.


P.S. I did ask this question in "Mozilla plans to reduce power consumption of Firefox," but no response back. Can these two threads be combined?

[__NM64__]

I'd rather parallelize system libraries instead (like I already do for some things).

Could you elaborate on this? I'm very interested in what could be done and what has already been done.

While you're at it, how blasphemous would it be to have all tabs and content on one process and the general browser UI on another? This was something that was not mentioned at all in the previous discussions of this thread and I would be very interested to hear how that would compare to e10 and no e10 in terms of both practicality and feasibility.

[Moonchild]

While you're at it, how blasphemous would it be to have all tabs and content on one process and the general browser UI on another?

Not necessarily blasphemous, but you'd create the same issues that e10s faces: it needs inter-process communication, and a LOT of it. How are you going to let the browser talk to the content process? how is rendered content going to be passed back to the main process? etc. etc.

For example: you create an extension that adds a UI control to do something with a page. How will that work if they are separate? It won't, unless you have an elaborate communication between the two processes catering to a random event caused by code that isn't even native to the browser, which has to be both asynchronous and low latency at the same time.
Basically this is how far they've gotten with e10s now, with having web content in one process and the main application in another in FF Nightly, if e10s is enabled, and it's still riddled with many bugs and incomplete.

[ninaholic]

Why would the entire rest of the industry be moving in a direction that didn't offer any advantages AND made things worse - something doesn't sit right with that idea.

By that logic, Australis and Windows 8 were great ideas. The "industry" has moved off a cliff imo. R.I.P. industry

[Eleventy_Threeve]

My experience was that on a modestly strong rig running about 75 modest tabs(no video) on Chromium nearly locked up the entire system. On that same computer my previous record was over 600 tabs in PM and it barely flinched. At the moment I am on a much stronger computer and I suspect that PM could easily handle thousands of tabs.

I don't see the benefit to making them all a new process. I vote to keep things just the way they are.

[__NM64__]

So uh... Moonchild, could you answer the first question?

[Moonchild]

So uh... Moonchild, could you answer the first question?

Compiler parallelization, pretty much. Or rather: properly changing code so it can be executed in parallel, then letting the compiler take advantage of it.
I've previously looked into using OpenMP but the implementation of that isn't particularly good in MSVC and seems unmaintained, so I've moved to the new built-in parallelizer instead, which has been in use for quite some time. See also: https://msdn.microsoft.com/en-us/librar ... 10%29.aspx

[freefrog]

For example: you create an extension that adds a UI control to do something with a page. How will that work if they are separate? It won't, unless you have an elaborate communication between the two processes catering to a random event caused by code that isn't even native to the browser, which has to be both asynchronous and low latency at the same time.
Basically this is how far they've gotten with e10s now, with having web content in one process and the main application in another in FF Nightly, if e10s is enabled, and it's still riddled with many bugs and incomplete.

Moonchild, in light of this example, in your opinion is there an efficient/practical way to develop an extensible web browser around a multi-process design? Or are the inherent trade-offs with multi-process simply not worth it?

[Moonchild]

The inherent trade-offs of multi-process (regardless of extensibility) are not worth it, in my opinion.

[snertev]

The inherent trade-offs of multi-process (regardless of extensibility) are not worth it, in my opinion.

Surely not on a code base of the age of Firefox.

Edt: I wrote Firefox for a reason: they are trying to migrate to a multi-process browser cutting code and future included in a venerable code base. IMO, that transformation may have a sense for a completely new code and user base.

[LimboSlam]

E10s/Electrolysis will not work for older PC's, now maybe for newer and faster ones, yes. But for me since my job mostly still uses Vista on a 2006-2007 built desktops/laptops and have multiple students running at the same time, Firefox can get very slow and crash if it doesn't respond in the 30 seconds wait time.

I've also compared Firefox with e10s enable to Pale Moon, Pale Moon is way snappier and much less a resource hog. So theirs really not an advantage. But we really won't know until it's finished, then we can have accurate results and criticize it.

[Moonchild]

Keep in mind that Firefox's current multi-process approach is still not their intended "process per tab" use, which will cause much more resource use because of much more overhead (web process overhead x number of tabs). I don't care what kind of modern PC someone has; opening 50 tabs in 50 processes that all chatter inter-process with the "main" (UI) process will cause a lot of extra load that multithreading within one process will never suffer from. Not even taking into account the massive switching load caused on the OS kernel to switch between the different processes and scheduling time slices according to load of each process.

It may keep the UI responsive even if a page misbehaves and maxes out a core in CPU usage, but that's thinking in small terms. The price to pay for it is that instead of the browser being slowed down, your entire system will be slowed down -- regardless of any of the opened pages misbehaving or not (and that in turn will, yes, also slow down the browser).

[weamish]

My experience was that on a modestly strong rig running about 75 modest tabs(no video) on Chromium nearly locked up the entire system. On that same computer my previous record was over 600 tabs in PM and it barely flinched. At the moment I am on a much stronger computer and I suspect that PM could easily handle thousands of tabs.

When running 50-75 tabs, can hit 2G+ memory use. It seems that difficulty with one tab can result in PM becoming unresponsive, requiring a shutdown and restart. Most of the time, the tabs will reload automatically, but not always (and the same errant tab may force another shutdown). With the risk of losing tabs, I'm leery of opening too many at once.

[snertev]

My experience was that on a modestly strong rig running about 75 modest tabs(no video) on Chromium nearly locked up the entire system. On that same computer my previous record was over 600 tabs in PM and it barely flinched. At the moment I am on a much stronger computer and I suspect that PM could easily handle thousands of tabs.

When running 50-75 tabs, can hit 2G+ memory use. It seems that difficulty with one tab can result in PM becoming unresponsive, requiring a shutdown and restart. Most of the time, the tabs will reload automatically, but not always (and the same errant tab may force another shutdown). With the risk of losing tabs, I'm leery of opening too many at once.

Nevertheless the current solution proposed from Mozilla is not a solution at all for this problem, because all content tabs are managed in 1 process anyway and adding more than 1 content process is already causing all sorts of issues:

https://bugzilla.mozilla.org/show_bug.cgi?id=991169
https://bugzilla.mozilla.org/show_bug.cgi?id=1051969
https://bugzilla.mozilla.org/show_bug.cgi?id=1081098
https://bugzilla.mozilla.org/show_bug.cgi?id=1098122
https://bugzilla.mozilla.org/show_bug.cgi?id=1142013
https://bugzilla.mozilla.org/show_bug.cgi?id=1165309
https://bugzilla.mozilla.org/show_bug.cgi?id=1191791
https://bugzilla.mozilla.org/show_bug.cgi?id=1207285
https://bugzilla.mozilla.org/show_bug.cgi?id=1212046
https://bugzilla.mozilla.org/show_bug.cgi?id=1213435 <-- nasty RAM issue still unexplored

and who knows how many more issues will arise after e10s will go main stream.

[__NM64__]

Random thought I had:

How realistic would it be to have one process per browser window (not tab)?

I guess this could include the likes of a private window as well.

[Moonchild]

How realistic would it be to have one process per browser window (not tab)?

It would be a lot more realistic from a resource use point of view, but has a few rather complex snags:

• How many people use more than 1 window or maybe 2? Probably a vast minority. So, how efficient will you be in that case? On an 8-core system, should you tell people to open 8 windows to efficiently use all cores of their CPU? This point alone quickly makes it a lot of effort for something that will be under-used.
• How are you going to handle tab dragging/dropping between windows without losing content?
• How are you going to handle pop-up windows/window.open() calls?
• How are you going to handle browser-encompassing data streams like history, bookmarks, content preferences, etc. that will then need concurrent profile access?

I can probably think of more, given time.

[__NM64__]

• How many people use more than 1 window or maybe 2? Probably a vast minority. So, how efficient will you be in that case? On an 8-core system, should you tell people to open 8 windows to efficiently use all cores of their CPU? This point alone quickly makes it a lot of effort for something that will be under-used.

I very rarely use multiple windows myself, but I was thinking that if separate windows were in a separate process that I personally would use them more, but not for my main browsing.

The idea is that it would make having a separate window be more distinct than just having a separate tab, because currently the only reason I even see for having a separate window is if you want to visually separate some tabs for anti-clutter reasons.


If having it in a separate process is still difficult, then what about a separate processing thread? This would at least allow the user to separate a few background webpages or specific CPU-intensive web applications as they see fit rather than the browser trying to automatically run as much as possible in separate threads.