Stories
Slash Boxes
Comments

SoylentNews is people

posted by cmn32480 on Thursday June 15 2017, @10:11AM   Printer-friendly
from the will-the-bloat-be-taken-out dept.

Firefox has improved its multi-process architecture in order to isolate more content while keeping memory use low:

Firefox 54 launched with a more advanced multi-process architecture than the one we saw implemented in Firefox 48 last year. The improved architecture raises the number of processes enabled by default from two to five, which Mozilla argues is a "just right" compromise between low memory usage on one side and performance and security on the other.

[...] Switching to a simpler extension model allows Firefox to enable multiple processes and also isolate them in sandboxes. Mozilla previously enabled only two processes, one for the UI and one for content, last year, in Firefox 48. This ensured that the browser wouldn't hang as much due to web pages affecting the performance of the browser interface. It also brought partial sandboxing by keeping the content isolated from the browser (as much as possible).

Mozilla is now taking it to the next level by implementing one process for the browser interface and four for content. Why four? The organization believes that this is the "just right" amount of processes to have for the majority of users, and also in terms of optimizing memory usage.

[...] Mozilla ran its own memory usage benchmarks, which showed significant memory usage reduction compared to Chrome:

  • Windows 10 — Chrome used 1.77X memory as Firefox (64-bit), and 2.44X as Firefox (32-bit)
  • macOS — Chrome used 1.36X memory as Firefox (64-bit)
  • Linux — Chrome used 1.42X memory as Firefox (64-bit)

Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 3, Informative) by pTamok on Friday June 16 2017, @08:12AM (1 child)

    by pTamok (3042) on Friday June 16 2017, @08:12AM (#526364)

    There's a fairly long and relatively informative discussion on this at lwn.net

    https://lwn.net/Articles/716668/ [lwn.net]

    I think what has happened is that the FFv53 binary was built with ALSA support not compiled in, but it was still available as an option if you compiled it yourself, which some distributions did. (The configure option, unsurprisingly, is --enable-alsa.)

    However, FF54 implements sandboxing in a way that can't currently use ALSA. So you can't just recompile with the appropriate flag set to get ALSA support (that is, --enable-also is not availablle for FF54). From my limited understanding, the PulseAudio daemon provides the necessary support to allow separate sandboxed processes to share the audio device, whereas with ALSA, the FF code would need to handle the device multiplexing itself (or least be changed to use ALSA in a different way*). So the developers have taken the easier route of using PulseAudio, saving them a job. Which is understandable, but irritating for people who either can't, or won't use PulseAudio on their systems (and there are legitimate reasons why this might be).

    My personal view on this is that it is a poor decision. ALSA is built in to the kernel, and so is pretty much guaranteed to be available on most, if not all Linux systems (bar those with custom-compiled kernels where someone might have decided to leave out audio support). PulseAudio is an optional addition to a system, and while you can argue it is reasonable to have certain requirements over and above the kernel for an application to run, PulseAudio is somewhat contentious to have as a requirement. That said, I'm not a coder, and the Mozilla developers will have a more informed view.

    *Note, ALSA does provide a software mixer - see this article https://ubuntuforums.org/showthread.php?t=539819 [ubuntuforums.org] ; and this documentation http://alsa.opensrc.org/Hardware_mixing,_software_mixing. [opensrc.org] However, if FF is coded to write directly to the hardware device, then changes would be needed to use the software device. Pulseaudio 'simply' hijacks/emulates the hardware device, and remixes in software before sending to the actual hardware. So code can continue to write to the hardware device, which is then intercepted by PulseAudio. It means the programmer doesn't have to re-code, but it means every application on the system that uses the hardware audio device is forced to go through PulseAudio, and some specialised audio applications don't like this

    Starting Score:    1  point
    Moderation   +2  
       Informative=2, Total=2
    Extra 'Informative' Modifier   0  

    Total Score:   3  
  • (Score: 1) by pTamok on Friday June 16 2017, @08:30AM

    by pTamok (3042) on Friday June 16 2017, @08:30AM (#526369)

    Sorry, wrong URL pasted in:

    the alsa.opensrc.org URL should be:

    should be http://alsa.opensrc.org/Hardware_mixing,_software_mixing [opensrc.org]