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.

102 comments

  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 Anonymous Coward · · Score: 0

      Well that's how chrome does it and they say it consumes more memory having every tab on separate process, thus they chose only 4 groups for firefox.
      Go figure.

    7. 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!
    8. 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.'"
    9. Re:Why processes instead of threads? by Anonymous Coward · · Score: 0

      They aren't using processes instead of threads. They're using both. Processes give better isolation than threads, but they don't create a new process for every single page. In fact, you'll probably have just 3 or so processes running in total no matter how many pages you have open - 1 process for all your pages and all threads related to those, 1 for your extensions, and 1 for the browser chrome, for example. If one of the threads causes a process to die it will take down all the threads in the same process, but then one of the other processes can see what happened and restore everything rather seamlessly.

    10. Re:Why processes instead of threads? by Anonymous Coward · · Score: 0

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

    11. Re:Why processes instead of threads? by Anonymous Coward · · Score: 0, Offtopic

      Ah, corporate mentality. Cut costs! Cut costs! No raises! Layoffs! But don't forget the next giant bonus for the executives.

    12. Re:Why processes instead of threads? by Anonymous Coward · · Score: 0

      Processes don't have shared state so are easier to reason about, less error prone, more portable, and indeed a lot more efficient on multi processor systems.

    13. Re:Why processes instead of threads? by Anonymous Coward · · Score: 0

      If only stdlib didn't bastardize anything they add when it comes to class objects.

      Any type of class object in stdlib is such a shit show of missing half the common functions you'd want and abstracting the shit out of the class that its difficult as hell to add functionality. Makes sense since most things come from the over complicated ugly as sin boost team.

      Sane people use stdlib for the generic stuff and roll there own for any object types.

      Outside of class objects its not near as bad.

    14. Re:Why processes instead of threads? by Anonymous Coward · · Score: 0

      You've clearly never used Java. Java makes developers pine over the thought of even the worst of C++.

    15. Re:Why processes instead of threads? by Anonymous Coward · · Score: 0

      Threads share an address space, meaning that if there's a memory corruption in one, it could potentially affect all other threads in that process.

      Processes have separate address spaces, meaning that a memory corruption in one shouldn't affect the others.

    16. 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.
    17. Re: Why processes instead of threads? by Anonymous Coward · · Score: 0

      False

    18. 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
    19. 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.
    20. Re:Why processes instead of threads? by Anonymous Coward · · Score: 0, Informative

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

      ^ This guy Firefoxes.

      p.s. Congratulations Firefox. You finally get to close this 8 year old bug.

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

    22. 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.
    23. Re:Why processes instead of threads? by Anonymous Coward · · Score: 0

      Can we give each a processor cycle budget?

    24. Re:Why processes instead of threads? by Anonymous Coward · · Score: 0

      I'm guessing you see thread shared address space as a feature?

      Hint: Everyone else sees a vulnerability in this context.

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

    26. 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."
    27. 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...
    28. Re:Why processes instead of threads? by Anonymous Coward · · Score: 0

      Another way to look at it: with threads, everything in the heap is a potential inter-thread communication channel including all the accidental stuff you get with thread-unsafe code which might be linked in.

      If your codebase is too sprawling to allow one to audit and guarantee thread safety, wedging in a thin IPC channel between a few instances of your legacy codebase is much safer. You can make sure that these communications only interact with thread-safe code, and all the rest of the heap remains private.

      If important parts of your runtime (such as your garbage collector) is unsafe, this goes doubly so. Run a couple instances of your single-threaded stack and all that stuff still works. Then, just introduce a more explicit communication mechanism between them which can even stick to message-passing via sockets or similar, something your typical browser stack already knows how to manage.

    29. Re:Why processes instead of threads? by toonces33 · · Score: 0

      No doubt the reason is that the thing is so bloated that they need 4 processes worth of address space.

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

    31. Re:Why processes instead of threads? by Anonymous Coward · · Score: 0

      Standard C++11 does have portable threads: http://www.cplusplus.com/reference/thread/thread/

      Major C++ compilers have supported C++11 for years. What are you talking about?

    32. Re:Why processes instead of threads? by Anonymous Coward · · Score: 0

      Yeah, not looking at the code, I wouldn't be surprised if they didn't just assign a tab to a process and call it a day. So now we'll get almost 4x the memory bloat, but less so as hopefully the O(2^N) algorithms dealing with tabs will have smallers Ns. Seriously, performance quickly degrades with the more tabs you have open even if you have scripts blocked. 1000 non-active tabs can give you a 30 minute start up time! If you close all those tabs you'll never end up with the same memory usage as opening with only 1 tab.

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

    34. Re: Why processes instead of threads? by Anonymous Coward · · Score: 0

      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.

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

    36. 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
    37. Re:Why processes instead of threads? by Anonymous Coward · · Score: 0

      Processes in Windows are much heavier than in Linux. Maybe they wanted to limit the user impact of a process-per-tab architecture in some platforms.

    38. Re:Why processes instead of threads? by Anonymous Coward · · Score: 0

      You mean more than the 400MB it already uses to have a few tabs open? Yikes. Good thing memory is cheap these days.

    39. 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"
    40. 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.
    41. Re:Why processes instead of threads? by Anonymous Coward · · Score: 0

      Because they have huge locking problems.

    42. Re:Why processes instead of threads? by Anonymous Coward · · Score: 0

      Threads are default shared, optionally with some private memory.

      Processes are default private, optionally with some shared memory.

    43. Re:Why processes instead of threads? by Anonymous Coward · · Score: 0

      because IPC is so much easier?

    44. 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
    45. 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.'"
    46. Re: Why processes instead of threads? by Anonymous Coward · · Score: 0

      They had a multi-thread model ever since they had tabs. They switched away from that multi-thread model towards multi-process.

      Even if you're trying as hard as you can, you're not gonna sound smart just by criticizing a decision of a big tech organization. You'll have to at least be smart enough to understand the context.

    47. 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.'"
    48. 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)

    2. Re:Android version by Anonymous Coward · · Score: 0

      Sailfish is excellent, and is not vaporware. I've been using it on my Nexus 4 for a long time now, and there are ports for many devices.

      If there's a version of CyanogenMOD or LineageOS available for your device, it's not difficult to port it yourself.

  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 Anonymous Coward · · Score: 0

    Would it really hurt to mention what the thing you are writing about actually is? Why assume that your readers know any and all obscure product?

    Nice job trying to make it seem like Firefox is completely irrelevant and unknown, Troll.

  6. 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!
  7. Re:Firefox? by Anonymous Coward · · Score: 0

    Everybody knows the helicopter Firefox. This article clearly is not discussing helicopters. The OP is 100% correct.

  8. 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.'"
  9. Is it complete? by Anonymous Coward · · Score: 0, Redundant

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

    1. 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.
    2. Re:Is it complete? by Anonymous Coward · · Score: 0

      Pocket can go DiaF. It's the first thing I remove when I install Firefox.

    3. Re:Is it complete? by Anonymous Coward · · Score: 0

      You mean the glue that tied it into firefox. But what about the functional code proper?

  10. 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!
  11. Noticed: 500+ % CPU usage by GNious · · Score: 0

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

    1. Re:Noticed: 500+ % CPU usage by Anonymous Coward · · Score: 0

      Definitely not happening here, and I'm running with 8 content processes on Linux, which should be a recipe for horrible CPU-maxing performance. Highly recommend filing a bug.

    2. Re:Noticed: 500+ % CPU usage by Anonymous Coward · · Score: 0

      I recommend you use something like Cinnamon with llvm-pipe as the 3D driver - modern software OpenGL - and enable as much hardware "acceleration" as you can (heard that Libre Office uses a library/framework that uses OpenGL for 2D acceleration. hahahhahaha)
      Try to find pulseaudio plugins to run all the time.
      Disable DMA for your hard drives. Live stream your desktop to a tablet, using h264, in case you want to go to the toilet and keep your desktop with you.
      Run a Windows 7 VM (Virtualbox is good for that) in the background, permanently so that it updates as soon as it can.
      Want to goof off? There are javascript game emulators you can run from your browser! even on archive.org I think (I have no idea why or why they don't get sued)

    3. Re:Noticed: 500+ % CPU usage by Anonymous Coward · · Score: 0

      I forgot : access your gigabit NAS with sshfs (and don't trust your desktop's hardware encryption)
      Whole disk encryption, compression and RAM compression are the way of the future and are here to stay.
      Install a software synth and play classic midi files from Dosbox.

    4. 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%

    5. 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
    6. Re: Noticed: 500+ % CPU usage by Anonymous Coward · · Score: 0

      I thnk yu ar missng a couple keys on yor keybord

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

    8. Re:Noticed: 500+ % CPU usage by Anonymous Coward · · Score: 0

      Which codec is the video playing under? VP9 is a bit more CPU intensive to playback than H264.

    9. Re: Noticed: 500+ % CPU usage by Anonymous Coward · · Score: 0

      I thnk yu ar missng a couple keys on yor keybord

      That's because he only have 100% keyboard. He needs at least 250%.

  12. Oh, great! by Anonymous Coward · · Score: 0

    Then there will be even less left over from my machine to do, you know, useful things.

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

      This.

      --
      CLI paste? paste.pr0.tips!
  13. Re:I've been on the ESR channel since its inceptio by Anonymous Coward · · Score: 0

    imho, everybody should be on firefox esr. 53 is horrible. testing release lasted all of two days here before getting kicked to the curb. never again. slower, more ram used (how the fuck was that even possible?) and so fucking unstable it hurt to use it.

  14. Re: What about their Javascript interpreter? by Anonymous Coward · · Score: 0

    Can you share a reference of any url that performs at you state?

  15. Re:I've been on the ESR channel since its inceptio by Anonymous Coward · · Score: 0

    > ...the added overhead of four processes will eat memory away, more so in the 64 bit version.

    It's remarkable how much more memory the multi-process version uses. For the same content, the multiprocess version uses at _least_ twice the RAM. I've no idea how they managed this, or why they thought it was acceptable. I was testing on FF 53, so maybe this is fixed in FF 54?

    > The penalty for the extra context switches will kill you.

    lolno. Context switches are effectively free on anything newer than like an 8086.

    Try this: Open Task Manager or top and count how many processes are running on your system right at this moment. (Enable the "show process threads" option to get a better count.). Each one of those processes and threads requires regular context switches to service. You probably have at least a couple-hundred processes and -when you add threads in- something more like a thousand runnable objects. Even if context switches _weren't_ free, four more processes are _not_ going to be noticeable.

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

    Here's the thing: AFAICT, Firefox won't enable multiprocess mode on systems that are too tiny to use it. On my Core2 Duo machine, I had to force-enable multiprocess mode.

  16. Re:I've been on the ESR channel since its inceptio by Anonymous Coward · · Score: 0

    Like the guy that replied to you I don't really agree with your reasons. In particular the number of process is a setting you can set (perhaps even under 52 ESR, and if you want two or five or eight "Web Content" processes you can)

    However there's a similar side of ESR to your need for weird plugin support, that's the tor browser. I might find myself using it more and more, and perhaps regular users should run it too (except for stuff like totalitarian mail services that believe you're a thief when you don't appear to access them from your home)
    This might make Firefox 52 more and more relevant and n+1 versions a bit less so.

  17. Re: What about their Javascript interpreter? by Anonymous Coward · · Score: 0

    I think he's ranting about Firefox crashing instead of silently infecting his computer when he visits his favorite Russian pr0n sites.

  18. Ah, thanks. Kinda. by Anonymous Coward · · Score: 0

    First of all, that's great news on improving FF stability.

    Also, throughout the years, I've depended on Firefox for the following things, which have had a big impact on my life:

    a) Making possible for me to browse the Internet on Linux, continuing the great job Netscape 4.7 once did;
    b) Allowing me to make secure transactions, including banking and applying for a job (which I got);
    c) Enabling smartcard-based authentication, which I've used in at least three different settings;
    d) Providing the best navigation experience, in the sense it is freer than with Chrome (for instance) -- because, for example, it allows me to use my 32-bit machines.

    I shall keep on using it, specially for more sophisticated usages.

    That said, there has been a warning about future supported hardware being restricted to post-Pentium IV machines.

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

  20. Re:Firefox? by Anonymous Coward · · Score: 0

    Air Wolf and Blue Thunder were helicopters. Fire Fox was a jet airplane.

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

  22. 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
  23. 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."
  24. 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 Anonymous Coward · · Score: 0

      You missed the argument about pulseaudio on firefox and 'removing' alsa support.

      Summary
      Us : wtf is this shit?
      Mozilla : fuck off

      There is also a large thread about it on /. You can still compile it with alsa support. I know default arch package does this.

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

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

  25. Re:I've been on the ESR channel since its inceptio by Anonymous Coward · · Score: 0

    Too bad they disabled non-pulseaudio sound even on ESR, instead of waiting for FF 53

  26. too late. by Anonymous Coward · · Score: 1

    Switched to Chromium. Using Pale Moon on older Hardware.

  27. Re:I've been on the ESR channel since its inceptio by Anonymous Coward · · Score: 0

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

    Refuse to install. That's nice. Now, if only newer Firefox versions would refuse to install when they are incompatible with add-ons, rather than installing and then informing the user that too bad, you need to dig out the installer for the old verison.

  28. Firefox is falling behind by Anonymous Coward · · Score: 0

    Its nice to see this finally implemented but Firefox is rapidly falling behind and has lost a lot of users. Really would like to see it make at least a decent comeback so we have some real pressure on Chrome. But I think its too little to late for Mozilla and Firefox. Would not surprise me to see Verizon dump ad support from the Yahoo Mozilla deal as soon as they can. This will pretty much be the end for Mozilla if that happens.

  29. 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
  30. 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...

  31. Re:I've been on the ESR channel since its inceptio by Anonymous Coward · · Score: 0

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

    You have about a year to find or construct an alternative workflow as the plugin support will disappear at the next ESR version..

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