Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Mozilla Firefox The Internet IT

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

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.
This discussion has been archived. No new comments can be posted.

Firefox 54 Arrives With Multi-Process Support For All Users

Comments Filter:
  • by JoeyRox ( 2711699 ) on Tuesday June 13, 2017 @01:44PM (#54611387)
    Why are they using 4 separate processes to improve load times of multiple tabs/windows instead of just multiple threads?
    • Re: (Score:2, Funny)

      by Anonymous Coward

      Multi-thread programming is hard. Hiring programmers who actually know what they're doing would cut into the money needed for fancy offices and other luxuries for Mozilla executives. They're only getting $1.8 Billion from Yahoo over the course of their 5 year contract. How are they possibly supposed to produce a decent browser on THAT budget.

    • by Anonymous Coward

      from what i understand , for security. to sandbox each website in its own process.

      • by aliquis ( 678370 )

        But that's not the case here either.

        Also you can of course decide which memory is shared or not using threads too.

        • I thought the idea was that one process could crater without taking the rest of the browser with it.

    • by thegreatbob ( 693104 ) on Tuesday June 13, 2017 @02:02PM (#54611515) Journal
      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... [semanticscholar.org]

      If anyone has insight on Windows multithreading performance, I'm all ears, as this may be one of the bigger reasons.
      • If only C++ had thread support natively since 2011, then we'd have something portable we could use for the last half decade in native code applications.
        • This is true and fortunate, but I was more so talking about the threading behavior of the underlying OS (which is abstracted to the programmer by the library du juor).
      • The article you linked compares Window's threads to Linux threads, both of which are implemented in a kernel-level thread implementation, so the document doesn't address the process vs thread question. As for security, separating browser sessions into processes vs threads doesn't achieve much - if a browser is compromised the persistence of that breach usually extends beyond one runtime session.
    • by williamyf ( 227051 ) on Tuesday June 13, 2017 @02:09PM (#54611561)

      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

      • by Kjella ( 173770 )

        Not to mention plain bugs... in Chrome that tab gets an "oops, we fucked up" but the browser as a whole pretty much never goes down. It's so annoying when you have tabs open that you're working on, open up a bunch of links to new tabs and boom goes your browser.

      • It can't be sandboxing, because they're apparently limiting this to four processes. As far as I can tell, this is purely about improving performance. Moving to separate processes is typically a bit tricker, because everything has to go through some sort of interprocess communication channel, unlike threads which have access to shared memory. Why they would use processes and then NOT take advantage of their sandboxing nature as a side benefit doesn't make sense to me. It also doesn't have the same inhere

        • No doubt the reason is that the thing is so bloated that they need 4 processes worth of address space.
          • They moved to 64 bit support even on Windows several releases ago. It would be pretty hard to bloat enough to occupy the 8 TB of user mode virtual address space currently available on 64 bit Windows without putting in some serious effort.
    • by Sloppy ( 14984 )

      Probably yadda yadda memory security yadda yadda but more importantly, because it's easier (faster; less programmers' time) and to reduce bugs. Wouldn't you use processes instead of threads, if you had a situation where you reasonably could? (i.e. if you didn't have to do a shitload of IPC?)

      • by unrtst ( 777550 ) on Tuesday June 13, 2017 @03:15PM (#54611979)

        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... [mozilla.org]
        That covers loads more info more accurately than any of these comments, my own included :-)

    • I don't know and I don't care. Look how rounded the tabs are!

    • by brianerst ( 549609 ) on Tuesday June 13, 2017 @04:14PM (#54612389) Homepage

      They explain it pretty thoroughly in their Medium post [medium.com] 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.

      • by AmiMoJo ( 196126 )

        I think I would prefer the extra security of one process per tab. My work machine has 8GB of RAM and runs loads of heavy development environments and CAD packages, and has no issue with Chrome having 49 processes.

      • It's mainly about using less memory. The maximum number of processes is configurable (about:config dom.ipc.processCount) and defaults to 4.

        It was set to 1 here, and it wasn't bold which means default, right?

        What's dom.ipc.processCount.extension for?

    • by AHuxley ( 892839 )
      We have the CPU's. The world needs a good OS. Something like what BeOS was. https://en.wikipedia.org/wiki/... [wikipedia.org]
      Then the application could work as expected. Until then the application has to work with existing big brand OS methods.
  • Almost Released (Score:2, Informative)

    by Anonymous Coward

    We're not quite released yet. Any minute now.

  • Android version (Score:4, Informative)

    by samwichse ( 1056268 ) on Tuesday June 13, 2017 @01:53PM (#54611449)

    Now if they would just make the Android version multiprocess as well.

    It's a real pig compared to Chrome, but it's the only Android browser I know of that supports plugins like uBlock and Disable HTML5 Autoplay.

    • by Anonymous Coward

      Firefox OS had multiprocess years ago and was the best mobile OS I ever used (this doesn't say much, as most mobile OS are dead like WebOS or vaporware like Sailfish, so I never tried them)

      Damn shame they tried a 128MB phone while people wanted a 1GB phone (it worked well with 512MB, since it only runs what you want to run and came out of the box with no nagging and stuff set to off)

  • Their website is still delivering the installer for 53.0.3

  • by williamyf ( 227051 ) on Tuesday June 13, 2017 @02:29PM (#54611681)

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

  • Noticed the change - Firefox now uses more than 500% cpu to play a YouTube video.

    • Am I the only one that hates tis way of accounting for cpu resourses? 500% used wrf 100% means all avalsble resources so when did thos 400 aditiional resorces magicly apear? Ot put snother way, what is the bencmark fpr 100%
    • Not a problem here (Windows, 64 bit browser). Windows counts out of 100%, and on a quad core 2.4 GHz Skylake laptop, it peaked at around 25% of CPU when the video was first loading (~100% by your standards), then dropped to ~5% (~25% by your measurements). I do have GPU acceleration enabled, which might be reducing the overhead a bit, but we're talking laptop grade GPU here, so it likely doesn't help much.
      • by GNious ( 953874 )

        Something is definitely funky - other browsers run at 10-15% when playing the same stream.
        In the past I've regularly seen it run at 100% (i.e. flatlining a core) when doing much of anything, but especially while receiving data. Been trimming ad-ons in the past to figure out if any of them is messing with it.

        The stream in question was/is the E3 2017 livestream from YT : https://gaming.youtube.com/e3 [youtube.com]

  • >"Firefox now uses up to four processes to run webpage content across all open tabs "

    I just hope they have and will retain a method to turn off such threading, too, when/if wanted. There are systems (yes, pretty rare, but they are out there) where having processes use more than one core/CPU can devastate performance for everyone else. User choice is important.

  • One of Firefox's strengths was that it would only max out one CPU core. Now it will take down all four. This is not progress.

    • In practice, I've yet to see meaningful CPU on more than one of the processes. The "main" process appears to be threaded and can actually occupy most of two cores for some time if you're on high resource web pages, but the other processes never spike very high or for very long; I suspect they're not processing page related stuff, so page triggered CPU meltdowns can't touch them.
  • I just installed version 54 from the tarball here, as my distro hasn't released the update yet. I'm not seeing those multiple processes though. Even with multiple tabs open and doing stuff it's still just the single process:


    $ ps -f $(pgrep firefox)
    UID PID PPID C STIME TTY STAT TIME CMD
    myuser 13561 13023 47 02:01 pts/3 00:01:41 ./firefox

    I do see multiple threads with ps -Lf, but version 53 was already doing that...

    Also, it seems that pulseaudio is now required to play audio. Fuck that sh

    • by cs96and ( 896123 )

      You might have an add-on installed that causes Firefox to disable its multi-process support.

      Go to about:support and look for "Multiprocess Windows". If it says "0/1" then it is disabled and will give you the reason why. The reason will probably be something like "Disabled due to an add-on", in which case, try disabling your add-ons one-by-one until you find the culprit.

    • Looks like (on my machine at least) when I upgraded, the process count setting was 1. Maybe it only defaults to 4 on fresh installs?

      Go to about:config -> dom.ipc.processCount

      Check if it's set to 1, or 4.

      Sam

  • by Anonymous Coward

    Switched to Chromium. Using Pale Moon on older Hardware.

  • v54 was still slow for me and I've been using the Developer version that had it enabled. I finally identified that e10s easn't enabled due to Mozilla's "Mozilla Archive Format" addon.
    http://maf.mozdev.org/ [mozdev.org]

    As far as I know, this is the only browser-based plugin that supports the MAFF archive format. It hasn't been updated whereas other developers were required to update their addons. I'm not sure if this means that MAFF is dead or if its just an oversight. (I've tried reaching out via email & Twitter

  • Comment removed based on user account deletion

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (10) Sorry, but that's too useful.

Working...