Firefox 54 Arrives With Multi-Process Support For All Users (venturebeat.com)

An anonymous reader writes: Mozilla today launched Firefox 54 for Windows, Mac, Linux, and Android. The new version includes the next major phase of multi-process support, which streamlines memory use, improving responsiveness and speed. The Electrolysis project, which is the largest change to Firefox code ever, is live. Firefox now uses up to four processes to run webpage content across all open tabs. This means that complex webpages in one tab have a much lower impact on responsiveness and speed in other tabs, and Firefox finally makes better use of your computer's hardware.

Comments

Why processes instead of threads?

[JoeyRox]

Why are they using 4 separate processes to improve load times of multiple tabs/windows instead of just multiple threads?

Re:Why processes instead of threads?

[thegreatbob]

I can't speak for their reasoning, but Windows threads are definitely less portable (multiproc should leave less cross-platform stuff to wrangle). Also shared address space and environment between threads and the main program (might be appropriate from a security standpoint). It used to be that Windows threads did not scale (performance-wise) very well, though I don't know how much that has changed since this was published:
https://pdfs.semanticscholar.o...

If anyone has insight on Windows multithreading performance, I'm all ears, as this may be one of the bigger reasons.

Re:Why processes instead of threads?

[williamyf]

Because it is the way is done in Chrome.

Now more seriously, is because of sandboxing. A process is forbiden to read or write on the memory space of another process, meanwhile every thread indide a process can read/write in the memory space of it's sister's threads (i am a spanish speaker. hebra=thread is femenine for us)...

So, if you used threads instead of processes, thread handling tab from malicious website a, coud trivially snoop/hack/crash websites in tabs b,c,d,e....

With processes, this becomes much much harder...

But in the end, is because chrome has been doing it like that since inception, and Firechrome-er i mean, fox, firefox, imitates chrome

Re:Why processes instead of threads?

[unrtst]

I wish someone replying on this actually knew why, rather than just guessing. (sorry to pick on this specific branch, Sloppy).

My understanding of it, and I haven't confirm this either, was that Firefox was moving to multi (initially 4?) processes, and each of those would be responsible for different areas and may have a bunch of threads within each. There are also different types of threads (user, kernel, etc), so these 4 processes may be implemented as heavy threads on windows.

The summary could have benefited from a link to the info on the e10s (electrolysis) project page: https://wiki.mozilla.org/Elect...
That covers loads more info more accurately than any of these comments, my own included :-)

Re:Why processes instead of threads?

[brianerst]

They explain it pretty thoroughly in their Medium post about Firefox 54.

It's mainly about using less memory. The maximum number of processes is configurable (about:config dom.ipc.processCount) and defaults to 4. During extensive testing, four processes gave the best combination of speed and memory utilization. Memory utilization was quite a bit lower than Chrome (Chrome used anywhere from 36-77% more RAM).

The first four tabs you open spin off individual processes and then new tabs are attached to existing processes (they don't say how this is done - round-robin or some sort of load balancer).

Four processes is supposed to be the best for systems that have 8G of RAM or less. If you have more, you can bump up the processCount.

Re:Is it complete?

[Champion3]

As in, does in include full source to this "pocket" contraption, now that mozilla bought the company?

The pocket client was always open source.

I've been on the ESR channel since its inception

[williamyf]

And word to the wise:

If you have old or underpowered hardware (as in only two threads, and lower than Core2 Duo), do not install this, and stick to 52-ESR. The penalty for the extra context switches will kill you.

If you are in a memory restricted machine, stick to 52 ESR, as the added overhead of four processes will eat memory away, more so in the 64 bit version.

If you depend on custom NPAPI plug-ins (other than flash), stick to 52ESR, as support for NPAPI (other than flash) is blocked in 53 and onwards.

If you are on XP, stick to 52ESR (this advice is redundant, as newer versions will refuse to intall on XP without some hacking).

If there are plugins that are essential to your workflow, consider either staying on 52 ESR, or do your due diligence, as this multiprocess breaks a lot of ad-ons.

Having said all that, I am happy that firefox is moving in this direction, which I think is the right one, and will bring massive benefits for the years to come in exchange for a little disconfort and inconvenience for a short while...

I am sad that I need to stay on 52ESR (as I need a lot of IPIMI plugins, sabameeting plugins, webex plugins, and lots of other crap to be effective at work).

Hope you enjoy betatesting this for us on the ESR channel, and polishing the rough edges.

Will be seeing you guys in about a year... ;-)