Multiprocess Firefox [e10s] (Partial Release: Fx48)

Omega X · Post by **Omega X** » December 4th, 2013, 8:05 pm

SnoutSpout · Post by **SnoutSpout** » December 4th, 2013, 8:46 pm

Admittedly, it will take some time to optimize the memory usage of multiprocess Firefox.

Elephant in the room. Admittedly Fx users are more sensitive to the issue than the average Chrome user, but I would suggest they wring this out as thoroughly as possible or it may undo all the goodwill the MemShrink work has bought in. (As a general rule of thumb I tend to think the Fx user uses more content tabs than users of other browsers, but this could just be anecdotal bias.) As for addons, the breakage will be massive, but e10s is so important I'm willing to let them at least try and see what the fallout is before judging. If there is some way to isolate the changes to a single config flag that's flipped to default only and only if everything is really ready, even better.

patrickjdempsey · Post by **patrickjdempsey** » December 4th, 2013, 8:55 pm

Glad to see they are taking addons support seriously. It doesn't matter HOW amazingly stable or responsive e10s is, if it breaks popular addons then there will be mutiny.

patrickjdempsey · Post by **patrickjdempsey** » December 4th, 2013, 8:58 pm

SnoutSpout wrote:
Admittedly, it will take some time to optimize the memory usage of multiprocess Firefox.

Elephant in the room. Admittedly Fx users are more sensitive to the issue than the average Chrome user, but I would suggest they wring this out as thoroughly as possible or it may undo all the goodwill the MemShrink work has bought in.

I think this is the major reason they are sticking with a single Content process model for now. They can get MOST of the benefits of multi-process without ballooning memory. 10Mb for the baseline Content-process is already dramatically better than what Cr does.

SnoutSpout · Post by **SnoutSpout** » December 4th, 2013, 9:09 pm

Communication (and not communication buried on dev blogs) is very important for Electrolysis, even far more than for Aust. Addon devs working on B2G/mobile versions of their own stuff will definitely keep themselves in the loop, but they're vastly in the minority and most addons will probably stay (and always be) desktop only. Early warning and lots and lots of hand-holding will be needed.

patrickjdempsey · Post by **patrickjdempsey** » December 4th, 2013, 9:19 pm

B2G/mobile addons stuff is TMK almost entirely being done in the SDK which will automatically support this (it's been built-in from the start). I'm not even sure if mobile even *supports* XPI-style addons?

SSweeorgch · Post by **SSweeorgch** » December 4th, 2013, 9:23 pm

Bill McCloskey's article links to a Project Wiki.

I think this section is important, if anyone is contemplating testing...

https://wiki.mozilla.org/Electrolysis#What_to_Expect

What doesn't work yet:

Session restore
Developer tools
Many addons
Many plugins
Click to play
Zooming

SnoutSpout · Post by **SnoutSpout** » December 4th, 2013, 9:30 pm

No XUL on Android, yes. But then again, if the dev is working on the mobile side and isn't planning to abandon his normal addons, he/she at least can't plead ignorance.

SnoutSpout · Post by **SnoutSpout** » December 4th, 2013, 9:40 pm

SSweeorgch wrote:What doesn't work yet:

Session restore
Developer tools
Many addons
Many plugins
Click to play
Zooming

Session Restore (implying a lot of tab management addons) is a dealbreaker for me, but it is very, very early days in the project yet unless we're talking piecemeal bits landing on the main trunk. In the meantime hopefully B2G will provide a representative testbed before most of the big bugs are completed.

RyanVM · Post by **RyanVM** » December 4th, 2013, 9:59 pm

patrickjdempsey wrote:Glad to see they are taking addons support seriously. It doesn't matter HOW amazingly stable or responsive e10s is, if it breaks popular addons then there will be mutiny.

Yeah, Servo is likely to break things badly, and the popular belief is that people will tolerate one major breakage but that more than that will lead to bigger losses.

patrickjdempsey · Post by **patrickjdempsey** » December 4th, 2013, 10:14 pm

I was thinking more of in the wake of Australis, which will break popular extensions... at least it will make them "disappear" in a way users might not like. It's taken over 2 years to deliver Australis. e10s is so far 4 years in the making and is I'm guessing still at *minimum* a year out, if not 2. So it's possible that by the time it is finally flipped on the Australis uproar will be over. But Servo is still largely *theoretical* and I'm not even entirely sure Mozilla will still be around by the time it's natural development cycle leads anywhere.

flaneurb · Post by **flaneurb** » December 4th, 2013, 10:57 pm

Omega X wrote:I figured since e10s is becoming a sure thing that its time to make a fresh thread.

Bill McCloskey wrote an in depth article on Multiprocess Firefox and is asking for input on the current state of the work:

http://billmccloskey.wordpress.com/2013 ... s-firefox/

Nice link. Thank you for posting it.

Grantius · Post by **Grantius** » December 4th, 2013, 11:10 pm

I was hoping they would go for a addon-compatible model that supported almost 100% of addons, even if it was a bit slower. Or similar to Chrome where each Jetpack addon uses its own process.

hopefully the addons I use update to use Jetpack so they work.

patrickjdempsey · Post by **patrickjdempsey** » December 4th, 2013, 11:57 pm

Grantius wrote:I was hoping they would go for a addon-compatible model that supported almost 100% of addons, even if it was a bit slower. Or similar to Chrome where each Jetpack addon uses its own process.

Not possible. *MANY* XPI extensions directly manipulate the DOM of websites, or fetch data from the web, and manipulate the interface simultaneously. Also, the way that XPI extensions are loaded into Firefox... they are actually loaded as PART OF the interface. You can split out the JS from an extension, but the XUL and XBL bits are loaded just like any other Firefox component. Which is exactly why the Firefox extensions system is the most powerful of any browser. That inter-connectivity and power comes at a price.

Jetpacks are pretty much modelled on Chrome extensions, and were designed from the ground-up to be multi-threaded and multi-process. But they also tend to be very tiny, so what would be the point of having them in their own process? Each Jetpack process would then have to load it's OWN copy of the SDK as overhead, and you would have to have messengers to talk to chrome as well as content... just seems like an incredible waste of resources for no real gain considering that the SDK is limited enough that it's doubtful that Jetpacks will be the source of crashes or slowdowns.

Grantius · Post by **Grantius** » December 5th, 2013, 12:52 am

patrickjdempsey wrote:
Grantius wrote:I was hoping they would go for a addon-compatible model that supported almost 100% of addons, even if it was a bit slower. Or similar to Chrome where each Jetpack addon uses its own process.

Not possible. *MANY* XPI extensions directly manipulate the DOM of websites, or fetch data from the web, and manipulate the interface simultaneously. Also, the way that XPI extensions are loaded into Firefox... they are actually loaded as PART OF the interface. You can split out the JS from an extension, but the XUL and XBL bits are loaded just like any other Firefox component. Which is exactly why the Firefox extensions system is the most powerful of any browser. That inter-connectivity and power comes at a price.

Jetpacks are pretty much modelled on Chrome extensions, and were designed from the ground-up to be multi-threaded and multi-process. But they also tend to be very tiny, so what would be the point of having them in their own process? Each Jetpack process would then have to load it's OWN copy of the SDK as overhead, and you would have to have messengers to talk to chrome as well as content... just seems like an incredible waste of resources for no real gain considering that the SDK is limited enough that it's doubtful that Jetpacks will be the source of crashes or slowdowns.

Thanks for the explanation. That makes things a ton clearer!

Multiprocess Firefox [e10s] (Partial Release: Fx48)

Multiprocess Firefox [e10s] (Partial Release: Fx48)

Re: Multiprocess Firefox [e10s]

Re: Multiprocess Firefox [e10s]

Re: Multiprocess Firefox [e10s]

Re: Multiprocess Firefox [e10s]

Re: Multiprocess Firefox [e10s]

Re: Multiprocess Firefox [e10s]

Re: Multiprocess Firefox [e10s]

Re: Multiprocess Firefox [e10s]

Re: Multiprocess Firefox [e10s]

Re: Multiprocess Firefox [e10s]

Re: Multiprocess Firefox [e10s]

Re: Multiprocess Firefox [e10s]

Re: Multiprocess Firefox [e10s]

Re: Multiprocess Firefox [e10s]