Slashdot Mirror

← Back to Stories (view on slashdot.org)

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

Posted by msmash on from the browser-news dept.

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.

51 of 102 comments (clear)

  1. Why processes instead of threads? by JoeyRox · · Score: 4, Insightful

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

    1. Re:Why processes instead of threads? by Anonymous Coward · · Score: 2, Funny

      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.

    2. Re:Why processes instead of threads? by Anonymous Coward · · Score: 1

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

    3. Re:Why processes instead of threads? by aliquis · · Score: 1

      But that's not the case here either.

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

    4. Re:Why processes instead of threads? by thegreatbob · · Score: 5, Insightful

      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.

      --
      There is no XUL, only WebExtensions...
    5. Re:Why processes instead of threads? by chuckugly · · Score: 1

      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.

    6. Re:Why processes instead of threads? by williamyf · · Score: 5, Informative

      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

      --
      *** Suerte a todos y Feliz dia!
    7. Re:Why processes instead of threads? by drinkypoo · · Score: 2

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

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    8. Re:Why processes instead of threads? by Champion3 · · Score: 1

      separate processes can run on different cpus (cores). threads are limited to the same cpu.

      Wrong. Threads are not limited to the same CPU.

      --
      I'm going to the casino. Don't gamble.
    9. Re:Why processes instead of threads? by Kjella · · Score: 1

      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.

      --
      Live today, because you never know what tomorrow brings
    10. Re:Why processes instead of threads? by Sloppy · · Score: 1

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

      --
      As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
    11. Re:Why processes instead of threads? by unrtst · · Score: 4, Informative

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

    12. Re:Why processes instead of threads? by Dutch+Gun · · Score: 1

      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 inherent robustness. If a process hangs or crashes, now instead of losing a single tab like in Chrome, you lose a quarter of them together.

      Well, we're looking from the outside in, so it's hard for us to determine what the reasoning was. They talk about memory streamlining, so maybe the intent is to keep the memory footprint lower by sharing common resources, like the rendering and Javascript systems. Maybe they figure Chrome's one weakness is its notoriously high memory use. Hard to say.

      --
      Irony: Agile development has too much intertia to be abandoned now.
    13. Re:Why processes instead of threads? by JoeyRox · · Score: 1

      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.

    14. Re:Why processes instead of threads? by Hognoxious · · Score: 1

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

      --
      Confucius say, "Find worm in apple - bad. Find half a worm - worse."
    15. Re:Why processes instead of threads? by thegreatbob · · Score: 1

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

      --
      There is no XUL, only WebExtensions...
    16. Re:Why processes instead of threads? by brianerst · · Score: 5, Informative

      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.

    17. Re:Why processes instead of threads? by chuckugly · · Score: 1

      Depends on the implementation but for Visual Studio the async stuff uses NT thread pooling.

    18. Re: Why processes instead of threads? by aliquis · · Score: 1

      You cannot decide which memory is shared using threads. When you use threads, all threads are the same process, and can read and write the same spaces in memory if you so choose.

      As far as I remember one used whatever locks to make sure the memory isn't used by two threads at the same time but I also assumed they could have both private and the shared RAM. They are the same process but surely threads can have their own memory too? Which isn't accessible by other threads? Or is that just how it's viewed in the language for convenience even though that's not the case? I do understand that some RAM / whatever was allocated before creating another thread or whatever (~15 years since I did anything with that) but I felt so sure it could still be just use for that thread as-well. May be class confusion or whatever but .. I still feel like it should be that way ;D.
      I'm willing to accept some RAM may be shared and I'm also willing to accept if how the OS renders stuff or grant network access or whatever require some parts to be shared between threads anyway. Of course I'm willing to accept anything as long as it come from someone with better knowledge who actually know their stuff say so :D

    19. Re:Why processes instead of threads? by ShadowRangerRIT · · Score: 1

      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.

      --
      $_ = "wftedskaebjgdpjgidbsmnjgcdwatb"; tr/a-z/oh, turtleneck Phrase Jar!/; print
    20. Re:Why processes instead of threads? by AHuxley · · Score: 1

      We have the CPU's. The world needs a good OS. Something like what BeOS was. https://en.wikipedia.org/wiki/...
      Then the application could work as expected. Until then the application has to work with existing big brand OS methods.

      --
      Domestic spying is now "Benign Information Gathering"
    21. Re: Why processes instead of threads? by Plus1Entropy · · Score: 1

      They are the same process but surely threads can have their own memory too? Which isn't accessible by other threads?

      There is no hard restriction on memory access between threads running in the same process. If you want to prevent memory by being accessed by other threads, you simply don't have them access that memory. The only time you need to implement a lock or semaphore is if multiple threads have access to the memory but only one at a time, and generally this isn't necessary unless multiple threads are actually writing to the location, rather than simply reading from it.

      --
      Only crack the nuts that crack. You don't put the ones that don't crack in the sack.
    22. Re:Why processes instead of threads? by AmiMoJo · · Score: 1

      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.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    23. Re:Why processes instead of threads? by drinkypoo · · Score: 1

      ^ This guy Firefoxes.

      I do. And what I have noticed since upgrading to 54 is that when Facebook punches Firefox in the nuts, I can actually recover the browser. That wasn't true with 53. I'm going to go ahead and give it the thumbs up.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    24. Re:Why processes instead of threads? by drinkypoo · · Score: 1

      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?

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    25. Re:Why processes instead of threads? by Wootery · · Score: 1

      optionally with some private memory.

      Like where? I've never seen this. Threads of the same process share a common memory-space by definition, no?

  2. Almost Released by Anonymous Coward · · Score: 2, Informative

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

  3. Android version by samwichse · · Score: 3, Informative

    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.

    1. Re:Android version by Anonymous Coward · · Score: 1

      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)

  4. Re: Firefox? by xxxJonBoyxxx · · Score: 2

    Back in the day it was like Chrome is today. Google supported it as an alternative to IE because it fed people into Google search/ads. With Chrome, Google's need for a surrogate shrank and so Firefox became the Al Gore of browsers.

  5. Re:Firefox? by Captain+Splendid · · Score: 1

    Hey, at least he put a little effort into it. Usually it's just HURR DURR FIREFOX IS STILL A THING ROFL

    --
    Linux, you magnificent bastard, I read the fucking manual!
  6. someone should tell them by drinkypoo · · Score: 2

    Their website is still delivering the installer for 53.0.3

    --
    "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
  7. Re:Is it complete? by Champion3 · · Score: 4, Informative

    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'm going to the casino. Don't gamble.
  8. I've been on the ESR channel since its inception by williamyf · · Score: 4, Informative

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

    --
    *** Suerte a todos y Feliz dia!
  9. I was all like... there's an Eric Raymond version? by gosand · · Score: 3, Funny

    I seriously didn't know what the ESR version of Firefox was until I just looked it up.
    I switched to Pale Moon in late 2016 and haven't looked back. I keep hearing about all these things FF is doing, and in the back of my head I am just screaming "JUST MAKE IT WORK". Maybe someday I'll go back to it, but until Pale Moon messes up, I have no reason to really.

    --

    My beliefs do not require that you agree with them.

  10. Re:Oh, great! by fisted · · Score: 1

    This.

    --
    CLI paste? paste.pr0.tips!
  11. Off by markdavis · · Score: 1

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

  12. It's bad news by gantry · · Score: 1

    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.

    1. Re:It's bad news by ShadowRangerRIT · · Score: 1

      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.

      --
      $_ = "wftedskaebjgdpjgidbsmnjgcdwatb"; tr/a-z/oh, turtleneck Phrase Jar!/; print
  13. Re:Firefox? by Hognoxious · · Score: 1

    My kid brother was really into those. I used to tease him by asking what time BlueKnightHawkWolfRacerTeam was on. They were all basically the same story, but with different vehicles.

    --
    Confucius say, "Find worm in apple - bad. Find half a worm - worse."
  14. Re: Noticed: 500+ % CPU usage by bn-7bc · · Score: 1

    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%

  15. I'm not seeing multiple processes by Spacelord · · Score: 1

    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 shit, I don't need more lennartware on my system.

    1. Re:I'm not seeing multiple processes by cs96and · · Score: 1

      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.

    2. Re:I'm not seeing multiple processes by samwichse · · Score: 1

      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

  16. Re:Noticed: 500+ % CPU usage by ShadowRangerRIT · · Score: 1

    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.

    --
    $_ = "wftedskaebjgdpjgidbsmnjgcdwatb"; tr/a-z/oh, turtleneck Phrase Jar!/; print
  17. too late. by Anonymous Coward · · Score: 1

    Switched to Chromium. Using Pale Moon on older Hardware.

  18. Re:Noticed: 500+ % CPU usage by GNious · · Score: 1

    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

  19. Re:I've been on the ESR channel since its inceptio by AmiMoJo · · Score: 1

    If you are on XP and browsing the internet, you are screwed no matter what you do.

    --
    const int one = 65536; (Silvermoon, Texture.cs)
    SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
  20. Mozilla's MAFF addon is not e10s compatible by GamesOver · · Score: 1

    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/

    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 over the past couple of months, but there's been no response.)

    Out of frustration regarding browser performance & non-communication, I finally switched to Chrome.

    1. Re:Mozilla's MAFF addon is not e10s compatible by zmk · · Score: 1

      http://maf.mozdev.org/document...

  21. New Perspective by Mkkby · · Score: 1

    I believe the browser makes very little difference. They are all awful/slow/insecure without a good ad blocker, script blocker and cookie blocker. Who cares if one is a few percent faster, when you are loading crap from dozens of domains? More threads doesn't matter to me because I'm blocking all the slow crap.

    Firefox just blew it by disabling the plug ins. I didn't give a crap about their features, so long as it worked well enough. I cared a HUGE AMOUNT about uBlock, noscript and disconnect. I'll stay on my current version for as long as it takes for plug in devs to catch up. I don't care how many years that takes.