12 ms·

Multiprocess Firefox

415 points by evilpie 13y ago

aquadrop 13y ago
It also brings the possibility to overcome ~4GB memory limit per x32 process. Which is nice.
- com2kid 13y ago
  Very nice indeed, I crash Firefox a few times a day from hitting the memory limit. Granted this is due to AB+ and Reddit Enhancement Suite. Although imo.im leaking memory over time doesn't help! (I am somewhat annoyed that an IM client takes up 500MB of memory, I miss Meebo!) Right now FF is at a fairly svelte 1.8GB. Heh. The other problem is that performance degrades dramatically as the number of open tabs increases. Once I hit 50 or so tabs scrolling becomes horribly jerky. From the sounds of it, this change may very well fix that as well. (For reference I am on an insanely fast home built machine!)
  - aquadrop 13y ago
    You can try Palemoon x64. I also had problems with crashing over memory limit. Was on Palemoon for 2 months and it works OK. I don't use many addons though.
  - ferongr 13y ago
    >Once I hit 50 or so tabs scrolling becomes horribly jerky That could be a GPU driver issue. GPU scheduling is generally horrible outside the "run a fullscreen game as fast as you can and screw everything else" usercase.
    - com2kid 13y ago
      Well in hopeful theory land those other tabs that aren't active shouldn't be hitting my GPU. :) I can also pop over to IE and it scrolls a-ok! (To be fair, IE11 has beautiful scrolling, everything else looks jerky in comparison, it really is quite a lovely effect!) But all my plugins are in FF, so.... with an SSD it is not like FF takes too long to come back up anyway! Still annoying though!
pjmlp 13y ago
I remember the days when for multiprocessing was the only option and multi-threading was only available on a few systems. Now with the security exploits many plugins have exposed and the way a misbehaved thread can bring the whole application down, we are moving back to the multiprocess model as a better sandbox model. Old becomes new as they say.
- sp332 13y ago
  It's always been a better sandbox model, but message passing is still a pain to orchestrate compared to shared-memory data structures.
  - csmuk 13y ago
    Personally I prefer message passing (over pipes). Shared memory (be it shm/heap in same process) with associated mutexes, semaphores, locks and the like is a right pain to get right without introducing race conditions, deadlocks etc. Go is interesting as it uses "micro threads" (goroutines) and message passing CSP style but I haven't found a use for it yet.
    - AndrewDucker 13y ago
      This is why Mozilla are investing heavily in Rust, so that they can use its semantics to share memory in a safe way.
      - pjmlp 13y ago
        Yes, I look forward to the day memory unsafe languages are only part of legacy systems.
    - rdtsc 13y ago
      > Go is interesting as it uses "micro threads" (goroutines) and message passing CSP style but I haven't found a use for it yet. But is also has shared heaps by default. So you still have to rely on everyone being an "adult". I wish shared heaps would have been a specially enabled feature not the default. But I guess the language was position to compete with C++ and Java and isolated heaps would have provided a performance decrease in benchmarks -- and thus people's willingness to adopt it. For large concurrent systems, safety and fault tolerance often leads to their failure but it is kind of hard to encode that in a quick benchmark to impress people. Here are a few languages/systems with default isolated heap runtimes between concurrency units: Dart's isolates, Erlang's processes, Nimrod's threads, Web Workers in modern browsers. Anyone know of more?
davidbielen 13y ago
breaks LastPass add-on
- cpeterso 13y ago
  Can you clarify how LastPass breaks? I installed LastPass and it seems to work for me with browser.tabs.remote=true.
josteink 13y ago
I'm very excited about this. I usually drive Firefox Beta without any sorts of complaints, but installed nightly just to try this out live. With my list of extensions[1] this doesn't seem to be particularly stable. It fails to bring up my tabs from last time. That would be OK for experimentation, had it not been for the fact that it also crashes regularly. These two combined really is test-stopper for me. Note: I'm not complaining. I'm very pleased this is being worked on. I'm just commenting first-hand experience about the state of things, so that others can make up their minds if they want to give it a go as well. [1] Installed extensions: Adblock Edge, Duckduckgo search, Firebug, Flashblock, Norwegian dictionary.
- cpeterso 13y ago
  Are the crashes listed in Firefox's about:crashes page? Filing bug reports with those crash IDs (which reference stack traces on crash-stats.mozilla.com) would be a big help. Firebug might be a problem because it is tightly coupled to Firefox's internal debugging APIs.
- handsomeransoms 13y ago
  Firebug is known to not work (and cause stability problems) at the moment (for reasons mentioned by cpeterso). We're working with addon developers to improve this situation.
- hansjorg 13y ago
  The Norwegian dictionary is very stable [1], so that shouldn't be the source of your problem. 1: http://språkrådet.no/Politikk-Fakta/Spraakpolitikk/ http://språkrådet.no/Politikk-Fakta/Spraakpolitikk/
paulrouget 13y ago
To try Electrolysis (multiprocess) in Firefox Nightly: in about:config, toggle the browser.tabs.remote pref and restart (still work-in-progress, don't expect a fully working browser). Edit: you will lose your current session
- frik 13y ago
  I tried it, sadly FF nightly crashed completely (not just a tab) every about 30 seconds with just 3 tabs open. The crash recovery dialog sent a log to Mozilla everytime, so they can hopefully fix the bugs soon.
fenesiistvan 13y ago
My biggest problem with Firefox is its startup time. It takes much longer to start the firefox.exe then IE and Chrome which are both very fast. I am using Win7 on i7-3960X, intel SSD, 16 GB RAM. If I install any plugin then this thing is much worst. (For this reason I am not using any plugin which is a big loss). It is weird that this issue is seldomly mentioned, but I think that it is much more important then the other performance benchmarks such as javascript performance.
- fenesiistvan 13y ago
  I am curious if the lack of such kind of complaint happens because usually people start their browser at morning and keep it open. I prefer to frequently close my browser and reopen when needed.
  - nextw33k 13y ago
    I think you underestimate how good modern operating systems are at memory management. I have 30+ tabs open (rather than bookmarking) and Firefox hasn't been closed for days. Spending developer time on things like start up and installers which are just 1% of what software does is not very productive. Yes its good to look at start up every now and again, however it shouldn't be the main focus of any project.
- ygra 13y ago
  Interestingly, that complaint no longer exists for me. Firefox really starts instantly. Which is unfortunate, as it's the first program in my task bar and I'm still used to use Win+Shift+1 to start a new instance. Which, if Firefox isn't already running, results in it asking whether I want to start in Safe mode because I was holding shift.
- nly 13y ago
  I don't have no/low tab cold start problems in either. ... that said, try closing Chromium with 20 odd tabs open and then reopening it. It'll take bloody ages to reload all those tabs. Firefox lazy tab loading saves a metric buttload of time in this scenario.
- 13y ago
JohnTHaller 13y ago
If you'd like to try this out on Windows without affecting your main Firefox profile, we just released portable packages of the Firefox Nightly and Aurora builds at PortableApps.com yesterday: http://portableapps.com/news/2013-12-04--firefox-aurora-27-and-nightly-28-portable-released http://portableapps.com/news/2013-12-04--firefox-aurora-27-a... They run self-contained in their own directory so you can quickly extract them to your Desktop or portable device. The installer downloads the latest build as you install it and configures it for standalone use. When you're done testing, you can just delete the FirefoxPortableNightly directory. Bonus: The Nightly branch also has the new Australis UI redesign that they've been working on and is worth checking out.
- dewarrn1 13y ago
  Works like a charm.
acjohnson55 13y ago
As a dedicated FF user, I've been waiting for this for so long. I may finally be able to isolate which tab is grinding my computer to a halt! As usual, this is amazing work.
kibwen 13y ago
For those of you interested in parallelism in browsers, I suggest you keep an eye on Mozilla's experimental new browser engine, Servo.[1] The goal is to make use of a variety of concurrency strategies (such as a Chrome-esque process-per-tab design[2]) and Rust's built-in support for memory-safe concurrency abstractions (fork/join, lightweight tasks, SIMD, etc.) to produce a ludicrously parallel[3] web browser. And even if Servo itself never happens to make its way into production, one of its purposes is to enable Mozilla to explore effective parallelism strategies to pursue with Gecko. [1] https://github.com/mozilla/servo/ https://github.com/mozilla/servo/ [2] I wasn't exactly thrilled about this myself, but as long as Servo has to interact with C++ code (notably, SpiderMonkey) this was judged critical for security. Fortunately, pcwalton seems to believe that Servo's tab processes will occupy less memory than Chrome's. [3] https://github.com/mozilla/servo/wiki/Design https://github.com/mozilla/servo/wiki/Design
- RHSeeger 13y ago
  I'll admit I wasn't a fan of process-per-tab originally either. However, since ever browser leaks memory, the ability to close some windows and reclaim the memory that was lost has been very useful to me (I tend to have 50+ tabs open at most times, and for many days at a time). That being said, I'd also be ok with process-per-window, as that would give me the same basic ability.
  - deeringc 13y ago
    It seems to me that "one process per window" would make it very difficult to implement dragging tabs between windows, and out into their own window.
    - repsilat 13y ago
      I guess it's a holdover from when I used Linux more often, but for most applications it seems sensible to just let the WM manage tabs. I guess there are a couple of situations when that approach is worse, though: - Tabs need to communicate with each other, or with a "host" application. In-process communication might be simpler than inter-process. - Some people have WMs that don't provide an acceptable tabbing interface, and you want your application to have an acceptable interface everywhere. In this case I guess I'd suggest distributing a separate tabbing program along with your app, but that kind of separation of responsibility has definitely gone out of fashion.
nly 13y ago
I welcome this just so we can determine which tabs are using the CPU persistently. I had to switch back to Chromium (after a good few weeks really giving FF another go) because I was sick of this issue. Firefox is smoother and more memory friendly than Chromium these days, a pleasure to use, but in Chrome I can kill hoggy tabs... so that's where I'm staying for the moment.
- girvo 13y ago
  Now, this isn't snarky, but you really run into issues like that, where its noticeably bad in a particular tab, enough to need to kill it? What sort of sites, and what processor?
  - nly 13y ago
    In Chromium it's generally runaway memory hogging tabs. Facebook is generally awful for example. Leave any Facebook page open all day (background of course, possibly on another virtual desktop) and you'll be staring at a multi-GB tab by evening. I'm not sure what's causing the CPU utilisation in Firefox. It's common to blame extensions in the FF community because there's no easy way to determine where the problem is.
  - andor 13y ago
    Every other day I hit the problem that a tab consumes so much CPU that it stutters. After closing that tab and reopening the same web site the issue is gone. That's using Chrome stable both on Linux and Android.
ritonlajoie 13y ago
From a code maintainance point of view, how do you manage to keep this 'branch' in track with the main one ? I mean, every patch made to the real firefox has to be carefully reviewed and backported to this multiprocess branch. Is that a manual process ? Or can it be automated like that : 1) Check if new commit arrived on 'head' 2) Auto backport it to the multiprocess branch 3) Try a build + run tests. Everything looks good ? Keep it 4) Not goot ? Send an email to the multiprocess maintainer so that he has a look ? Is there another way to do that ?
- RunningDroid 13y ago
  The multiprocess code is in the main branch, just not enabled by default.
- coyotebush 13y ago
  Since multiprocess is in the regular Nightly, the code is in the main line of development (mozilla-central). Based on the preference, it decides at runtime how to handle the content/chrome interface. But when Mozilla does branch off separate trees, VCS merges and lots of automated tests are largely sufficient.
mariusmg 13y ago
Not sure why we need this. Without plugins (flash, java, silverlight) , firefox IS pretty stabled.
- TrainedMonkey 13y ago
  Because my firefox often freezes for a while when I open something like video section of thedailyshow.com Given how cheap memory is, and the fact that almost all new devices are multicore I see this as a big positive.
- pekk 13y ago
  Do you honestly think it is reasonable to expect everyone not to use any plugins? Let me know how they are going to, say, get audio from webapps. I guess everything is stable, if you just avoid all the features everyone uses.
  - hsivonen 13y ago
    > Let me know how they are going to, say, get audio from webapps. HTML <audio>? Web Audio API?
- kunil 13y ago
  Because "one bad js = frozen browser" is bad
- darkstalker 13y ago
  It's needed to attract the die hard Chrome users back to Firefox.
- reubenmorais 13y ago
  This is more about responsiveness. It's not just about slow script, if you open a very large text file in a tab, the entire Firefox UI stalls. If you have some moderately heavy operation happening in a different tab, scrolling gets choppy across the board, switching tabs is janky, etc etc etc.
- khuey 13y ago
  Firefox has run plugins out of process for years.
efuquen 13y ago
It's unfortunate how behind the curve Mozilla is on this. No denying this was a huge undertaking but the length of time it's taken has obviously been detrimental to Firefox usage, the only real reason I still use Chrome as my primary browser. Though I'll give Electrolysis a shot with Firefox Nightly and see how it works out.
- why-el 13y ago
  Huh? I don't get this. Mozilla is switching from a single-process model to a multi-one. Chrome was built that way from say one. I hope you see that moving from different models costs more time then actually pick one and support it forever.
  - sanxiyn 13y ago
    You have a good point about switching cost. On the other hand, Chrome always could be run with --single-process (mainly there to measure the overhead of multiprocess), so it didn't really "pick one".
    - pcwalton 13y ago
      Chromium's --no-remote is pretty busted these days, in my experience. Basic browsing sorta works, but little else does.
    - reubenmorais 13y ago
      Once you have a multi-process setup in place, running in a single process is relatively simple, IPC just routes messages internally instead of across processes. Having a single-process setup and going to a multi-process one is a way, way, way larger effort.
  - Crito 13y ago
    Electrolysis was stalled and/or deprioritized for something like two years, with no apparent progress.
- tedmielczarek 13y ago
timothya 13y ago
> All IPC happens using the Chromium IPC libraries Interesting that they chose to share code with Chrome. Since the two are competitors, I would have thought that they'd use completely separate implementations. It's interesting that open source makes this sharing possible.
- timdiggerm 13y ago
  If someone's already written a perfectly good solution that's readily available you either - pridefully write your own - use theirs
  - arsenerei 13y ago
    I'm curious, why does pride come into the equation?
    - Mindless2112 13y ago
      If the existing implementation is perfectly good, writing your own is either pride, stupidity, or a learning exercise. I would take for granted that the Firefox developers aren't stupid, and that they have enough interesting work to do that they aren't going to spend time on it as a learning exercise.
      - arsenerei 13y ago
        Ah, okay. That feels a hyperbolic to be pride or stupidity, rather than just a poor analysis of the efficacy of an existing solution. Thank you for your response.
  - baq 13y ago
    it took a bit of time for me to take serious pride in using other people's work. it's been so much easier to deliver anything since then.
  - trustfundbaby 13y ago
    I don't think pride always enters into it, sometimes you just need diversity of thought around a problem. "We have to reinvent the wheel every once in a while, not because we need a lot of wheels; but because we need a lot of inventors." - Bruce Joyce
deleted 13y ago
[deleted]
- reubenmorais 13y ago
  The article explains it. Moving things off the UI thread (and other responsiveness related fixes) is what has been done so far as part of Snappy. This project is about putting web content in a different process than the Firefox UI.
Too 13y ago
Can this also solve the issue of flash objects taking over all keyboard input and breaking the standard hotkeys?
- jrockway 13y ago
  No.
- nephyrin 13y ago
  Gecko plugin peer here: Unfortunately, no. NPAPI has two modes: windowed and windowless. In windowless mode (roughly): we proxy input to flash, and flash renders into a buffer we provide it. In windowed mode, we create a native OS child window for flash and let it handle input and rendering directly. In this mode, without a way for flash to pass "unused" keys back to us, it will require some ugly hacks to steal hotkeys from it reliably. Most sites run flash in windowed mode, and for good reason - flash's performance sucks in windowless mode, and it cannot make use of hardware acceleration (IIRC). Since Adobe's NPAPI flash seems to be essentially in stability mode, it's unlikely this will be improved :( Now, in current multiprocess mode, we actually force flash to use windowless mode -- because support for windowed mode isn't finished yet (bug 923746). But the aforementioned performance issues mean that we'll probably remove that restriction once we support windowed mode in multiprocess.
Groxx 13y ago
Testing it out now, so far so good! I might make this my default profile, I would love not having rogue tabs freeze the entire system. It's very nearly my one remaining thing I prefer Chrome for, Firefox has really improved lately.
shmerl 13y ago
What about IPC embedding API? It already separates the UI from the heavy Gecko processing: https://wiki.mozilla.org/Embedding/IPCLiteAPI https://wiki.mozilla.org/Embedding/IPCLiteAPI I just hope Mozilla won't go extreme, and won't use a separate process for each tab like Chrome does. It produces memory bloat if you have many tabs open. While they say they'll mitigate memory issues, this should be balanced.
ksec 13y ago
I really wish all these could be speed up by us Kickstarting it or donating on it. It has taken far too long for e10s.
goggles99 13y ago
This is a terrible idea. There is no justifiable reason to do this. The reasons given are weak, this is just more over engineering that will add an enormous amount of complexity and add no real value. Lets look at the reasons given as to why they want to do this. >Performance. Most performance work at Mozilla over the last two years has focused on responsiveness of the browser. The goal is to reduce "jank"—those times when the browser seems to briefly freeze when loading a big page, typing in a form, or scrolling. You can do all of this with proper threading and task delegation. Putting things in separate processes will not magically make things better. The answer to "jank" is proper coding, not over engineering. Last time I checked there was the same "jank" in IE and Chrome even though they use MPs. >Security. Technically, sandboxing doesn’t require multiple processes. However, a sandbox that covered the current (single) Firefox process wouldn’t be very useful. Sandboxes are only able to prevent processes from performing actions that a well-behaved process would never do. Unfortunately, a well-behaved Firefox process (especially one with add-ons installed) needs access to much of the network and file system. This is BS. You could have three processes and have FireFox sandboxed completely. Main process runs in a low integrity mode which limits it's resource access to a single directory. Second process is a download delegation process (takes a file after it is downloaded and moves it to the requested location while also promoting it's integrity) running in normal integrity mode. Third process is a network communication delegate/proxy running in normal or possibly even low integrity. These two delegate processes I mentioned will still be needed for the MP Firefox so it is no more work to create them. >Stability This is the only true benefit, but it is of very little value. Firefox almost never crashes and when it does, the session restore brings you back to were you left off in seconds. Cons? More complexity means more bugs. This is a workaround for really fixing FireFox. I am going to have 150+ extra processes in my task manager now. More memory use. More context switches in the operating system eating up resources and causing more system latency and overall slowdown (context switches at the kernel level which will affect the whole OS).
- goggles99 13y ago
  LOL, I posted this same message on the blog comments and they deleted it. Nothing like censorship to stifle opposing opinions.

415 points by evilpie 13y ago

aquadrop 13y ago

It also brings the possibility to overcome ~4GB memory limit per x32 process. Which is nice.

com2kid 13y ago
Very nice indeed, I crash Firefox a few times a day from hitting the memory limit. Granted this is due to AB+ and Reddit Enhancement Suite. Although imo.im leaking memory over time doesn't help! (I am somewhat annoyed that an IM client takes up 500MB of memory, I miss Meebo!) Right now FF is at a fairly svelte 1.8GB. Heh. The other problem is that performance degrades dramatically as the number of open tabs increases. Once I hit 50 or so tabs scrolling becomes horribly jerky. From the sounds of it, this change may very well fix that as well. (For reference I am on an insanely fast home built machine!)
- aquadrop 13y ago
  You can try Palemoon x64. I also had problems with crashing over memory limit. Was on Palemoon for 2 months and it works OK. I don't use many addons though.
- ferongr 13y ago
  >Once I hit 50 or so tabs scrolling becomes horribly jerky That could be a GPU driver issue. GPU scheduling is generally horrible outside the "run a fullscreen game as fast as you can and screw everything else" usercase.
  - com2kid 13y ago
    Well in hopeful theory land those other tabs that aren't active shouldn't be hitting my GPU. :) I can also pop over to IE and it scrolls a-ok! (To be fair, IE11 has beautiful scrolling, everything else looks jerky in comparison, it really is quite a lovely effect!) But all my plugins are in FF, so.... with an SSD it is not like FF takes too long to come back up anyway! Still annoying though!

pjmlp 13y ago

I remember the days when for multiprocessing was the only option and multi-threading was only available on a few systems. Now with the security exploits many plugins have exposed and the way a misbehaved thread can bring the whole application down, we are moving back to the multiprocess model as a better sandbox model. Old becomes new as they say.

sp332 13y ago
It's always been a better sandbox model, but message passing is still a pain to orchestrate compared to shared-memory data structures.
- csmuk 13y ago
  Personally I prefer message passing (over pipes). Shared memory (be it shm/heap in same process) with associated mutexes, semaphores, locks and the like is a right pain to get right without introducing race conditions, deadlocks etc. Go is interesting as it uses "micro threads" (goroutines) and message passing CSP style but I haven't found a use for it yet.
  - AndrewDucker 13y ago
    This is why Mozilla are investing heavily in Rust, so that they can use its semantics to share memory in a safe way.
    - pjmlp 13y ago
      Yes, I look forward to the day memory unsafe languages are only part of legacy systems.
  - rdtsc 13y ago
    > Go is interesting as it uses "micro threads" (goroutines) and message passing CSP style but I haven't found a use for it yet. But is also has shared heaps by default. So you still have to rely on everyone being an "adult". I wish shared heaps would have been a specially enabled feature not the default. But I guess the language was position to compete with C++ and Java and isolated heaps would have provided a performance decrease in benchmarks -- and thus people's willingness to adopt it. For large concurrent systems, safety and fault tolerance often leads to their failure but it is kind of hard to encode that in a quick benchmark to impress people. Here are a few languages/systems with default isolated heap runtimes between concurrency units: Dart's isolates, Erlang's processes, Nimrod's threads, Web Workers in modern browsers. Anyone know of more?

davidbielen 13y ago

breaks LastPass add-on

cpeterso 13y ago
Can you clarify how LastPass breaks? I installed LastPass and it seems to work for me with browser.tabs.remote=true.

josteink 13y ago

I'm very excited about this. I usually drive Firefox Beta without any sorts of complaints, but installed nightly just to try this out live. With my list of extensions[1] this doesn't seem to be particularly stable. It fails to bring up my tabs from last time. That would be OK for experimentation, had it not been for the fact that it also crashes regularly. These two combined really is test-stopper for me. Note: I'm not complaining. I'm very pleased this is being worked on. I'm just commenting first-hand experience about the state of things, so that others can make up their minds if they want to give it a go as well. [1] Installed extensions: Adblock Edge, Duckduckgo search, Firebug, Flashblock, Norwegian dictionary.

cpeterso 13y ago
Are the crashes listed in Firefox's about:crashes page? Filing bug reports with those crash IDs (which reference stack traces on crash-stats.mozilla.com) would be a big help. Firebug might be a problem because it is tightly coupled to Firefox's internal debugging APIs.
handsomeransoms 13y ago
Firebug is known to not work (and cause stability problems) at the moment (for reasons mentioned by cpeterso). We're working with addon developers to improve this situation.
hansjorg 13y ago
The Norwegian dictionary is very stable [1], so that shouldn't be the source of your problem. 1: http://språkrådet.no/Politikk-Fakta/Spraakpolitikk/ http://språkrådet.no/Politikk-Fakta/Spraakpolitikk/

paulrouget 13y ago

To try Electrolysis (multiprocess) in Firefox Nightly: in about:config, toggle the browser.tabs.remote pref and restart (still work-in-progress, don't expect a fully working browser). Edit: you will lose your current session

frik 13y ago
I tried it, sadly FF nightly crashed completely (not just a tab) every about 30 seconds with just 3 tabs open. The crash recovery dialog sent a log to Mozilla everytime, so they can hopefully fix the bugs soon.

fenesiistvan 13y ago

My biggest problem with Firefox is its startup time. It takes much longer to start the firefox.exe then IE and Chrome which are both very fast. I am using Win7 on i7-3960X, intel SSD, 16 GB RAM. If I install any plugin then this thing is much worst. (For this reason I am not using any plugin which is a big loss). It is weird that this issue is seldomly mentioned, but I think that it is much more important then the other performance benchmarks such as javascript performance.

fenesiistvan 13y ago
I am curious if the lack of such kind of complaint happens because usually people start their browser at morning and keep it open. I prefer to frequently close my browser and reopen when needed.
- nextw33k 13y ago
  I think you underestimate how good modern operating systems are at memory management. I have 30+ tabs open (rather than bookmarking) and Firefox hasn't been closed for days. Spending developer time on things like start up and installers which are just 1% of what software does is not very productive. Yes its good to look at start up every now and again, however it shouldn't be the main focus of any project.
ygra 13y ago
Interestingly, that complaint no longer exists for me. Firefox really starts instantly. Which is unfortunate, as it's the first program in my task bar and I'm still used to use Win+Shift+1 to start a new instance. Which, if Firefox isn't already running, results in it asking whether I want to start in Safe mode because I was holding shift.
nly 13y ago
I don't have no/low tab cold start problems in either. ... that said, try closing Chromium with 20 odd tabs open and then reopening it. It'll take bloody ages to reload all those tabs. Firefox lazy tab loading saves a metric buttload of time in this scenario.
13y ago

JohnTHaller 13y ago

If you'd like to try this out on Windows without affecting your main Firefox profile, we just released portable packages of the Firefox Nightly and Aurora builds at PortableApps.com yesterday: http://portableapps.com/news/2013-12-04--firefox-aurora-27-and-nightly-28-portable-released http://portableapps.com/news/2013-12-04--firefox-aurora-27-a... They run self-contained in their own directory so you can quickly extract them to your Desktop or portable device. The installer downloads the latest build as you install it and configures it for standalone use. When you're done testing, you can just delete the FirefoxPortableNightly directory. Bonus: The Nightly branch also has the new Australis UI redesign that they've been working on and is worth checking out.

dewarrn1 13y ago
Works like a charm.

acjohnson55 13y ago

As a dedicated FF user, I've been waiting for this for so long. I may finally be able to isolate which tab is grinding my computer to a halt! As usual, this is amazing work.

kibwen 13y ago

For those of you interested in parallelism in browsers, I suggest you keep an eye on Mozilla's experimental new browser engine, Servo.[1] The goal is to make use of a variety of concurrency strategies (such as a Chrome-esque process-per-tab design[2]) and Rust's built-in support for memory-safe concurrency abstractions (fork/join, lightweight tasks, SIMD, etc.) to produce a ludicrously parallel[3] web browser. And even if Servo itself never happens to make its way into production, one of its purposes is to enable Mozilla to explore effective parallelism strategies to pursue with Gecko. [1] https://github.com/mozilla/servo/ https://github.com/mozilla/servo/ [2] I wasn't exactly thrilled about this myself, but as long as Servo has to interact with C++ code (notably, SpiderMonkey) this was judged critical for security. Fortunately, pcwalton seems to believe that Servo's tab processes will occupy less memory than Chrome's. [3] https://github.com/mozilla/servo/wiki/Design https://github.com/mozilla/servo/wiki/Design

RHSeeger 13y ago
I'll admit I wasn't a fan of process-per-tab originally either. However, since ever browser leaks memory, the ability to close some windows and reclaim the memory that was lost has been very useful to me (I tend to have 50+ tabs open at most times, and for many days at a time). That being said, I'd also be ok with process-per-window, as that would give me the same basic ability.
- deeringc 13y ago
  It seems to me that "one process per window" would make it very difficult to implement dragging tabs between windows, and out into their own window.
  - repsilat 13y ago
    I guess it's a holdover from when I used Linux more often, but for most applications it seems sensible to just let the WM manage tabs. I guess there are a couple of situations when that approach is worse, though: - Tabs need to communicate with each other, or with a "host" application. In-process communication might be simpler than inter-process. - Some people have WMs that don't provide an acceptable tabbing interface, and you want your application to have an acceptable interface everywhere. In this case I guess I'd suggest distributing a separate tabbing program along with your app, but that kind of separation of responsibility has definitely gone out of fashion.

nly 13y ago

I welcome this just so we can determine which tabs are using the CPU persistently. I had to switch back to Chromium (after a good few weeks really giving FF another go) because I was sick of this issue. Firefox is smoother and more memory friendly than Chromium these days, a pleasure to use, but in Chrome I can kill hoggy tabs... so that's where I'm staying for the moment.

girvo 13y ago
Now, this isn't snarky, but you really run into issues like that, where its noticeably bad in a particular tab, enough to need to kill it? What sort of sites, and what processor?
- nly 13y ago
  In Chromium it's generally runaway memory hogging tabs. Facebook is generally awful for example. Leave any Facebook page open all day (background of course, possibly on another virtual desktop) and you'll be staring at a multi-GB tab by evening. I'm not sure what's causing the CPU utilisation in Firefox. It's common to blame extensions in the FF community because there's no easy way to determine where the problem is.
- andor 13y ago
  Every other day I hit the problem that a tab consumes so much CPU that it stutters. After closing that tab and reopening the same web site the issue is gone. That's using Chrome stable both on Linux and Android.

ritonlajoie 13y ago

From a code maintainance point of view, how do you manage to keep this 'branch' in track with the main one ? I mean, every patch made to the real firefox has to be carefully reviewed and backported to this multiprocess branch. Is that a manual process ? Or can it be automated like that : 1) Check if new commit arrived on 'head' 2) Auto backport it to the multiprocess branch 3) Try a build + run tests. Everything looks good ? Keep it 4) Not goot ? Send an email to the multiprocess maintainer so that he has a look ? Is there another way to do that ?

RunningDroid 13y ago
The multiprocess code is in the main branch, just not enabled by default.
coyotebush 13y ago
Since multiprocess is in the regular Nightly, the code is in the main line of development (mozilla-central). Based on the preference, it decides at runtime how to handle the content/chrome interface. But when Mozilla does branch off separate trees, VCS merges and lots of automated tests are largely sufficient.

mariusmg 13y ago

Not sure why we need this. Without plugins (flash, java, silverlight) , firefox IS pretty stabled.

TrainedMonkey 13y ago
Because my firefox often freezes for a while when I open something like video section of thedailyshow.com Given how cheap memory is, and the fact that almost all new devices are multicore I see this as a big positive.
pekk 13y ago
Do you honestly think it is reasonable to expect everyone not to use any plugins? Let me know how they are going to, say, get audio from webapps. I guess everything is stable, if you just avoid all the features everyone uses.
- hsivonen 13y ago
  > Let me know how they are going to, say, get audio from webapps. HTML <audio>? Web Audio API?
kunil 13y ago
Because "one bad js = frozen browser" is bad
darkstalker 13y ago
It's needed to attract the die hard Chrome users back to Firefox.
reubenmorais 13y ago
This is more about responsiveness. It's not just about slow script, if you open a very large text file in a tab, the entire Firefox UI stalls. If you have some moderately heavy operation happening in a different tab, scrolling gets choppy across the board, switching tabs is janky, etc etc etc.
khuey 13y ago
Firefox has run plugins out of process for years.

efuquen 13y ago

It's unfortunate how behind the curve Mozilla is on this. No denying this was a huge undertaking but the length of time it's taken has obviously been detrimental to Firefox usage, the only real reason I still use Chrome as my primary browser. Though I'll give Electrolysis a shot with Firefox Nightly and see how it works out.

why-el 13y ago
Huh? I don't get this. Mozilla is switching from a single-process model to a multi-one. Chrome was built that way from say one. I hope you see that moving from different models costs more time then actually pick one and support it forever.
- sanxiyn 13y ago
  You have a good point about switching cost. On the other hand, Chrome always could be run with --single-process (mainly there to measure the overhead of multiprocess), so it didn't really "pick one".
  - pcwalton 13y ago
    Chromium's --no-remote is pretty busted these days, in my experience. Basic browsing sorta works, but little else does.
  - reubenmorais 13y ago
    Once you have a multi-process setup in place, running in a single process is relatively simple, IPC just routes messages internally instead of across processes. Having a single-process setup and going to a multi-process one is a way, way, way larger effort.
- Crito 13y ago
  Electrolysis was stalled and/or deprioritized for something like two years, with no apparent progress.
tedmielczarek 13y ago

timothya 13y ago

> All IPC happens using the Chromium IPC libraries Interesting that they chose to share code with Chrome. Since the two are competitors, I would have thought that they'd use completely separate implementations. It's interesting that open source makes this sharing possible.

timdiggerm 13y ago
If someone's already written a perfectly good solution that's readily available you either - pridefully write your own - use theirs
- arsenerei 13y ago
  I'm curious, why does pride come into the equation?
  - Mindless2112 13y ago
    If the existing implementation is perfectly good, writing your own is either pride, stupidity, or a learning exercise. I would take for granted that the Firefox developers aren't stupid, and that they have enough interesting work to do that they aren't going to spend time on it as a learning exercise.
    - arsenerei 13y ago
      Ah, okay. That feels a hyperbolic to be pride or stupidity, rather than just a poor analysis of the efficacy of an existing solution. Thank you for your response.
- baq 13y ago
  it took a bit of time for me to take serious pride in using other people's work. it's been so much easier to deliver anything since then.
- trustfundbaby 13y ago
  I don't think pride always enters into it, sometimes you just need diversity of thought around a problem. "We have to reinvent the wheel every once in a while, not because we need a lot of wheels; but because we need a lot of inventors." - Bruce Joyce

deleted 13y ago

[deleted]

reubenmorais 13y ago
The article explains it. Moving things off the UI thread (and other responsiveness related fixes) is what has been done so far as part of Snappy. This project is about putting web content in a different process than the Firefox UI.

Too 13y ago

Can this also solve the issue of flash objects taking over all keyboard input and breaking the standard hotkeys?

jrockway 13y ago
No.
nephyrin 13y ago
Gecko plugin peer here: Unfortunately, no. NPAPI has two modes: windowed and windowless. In windowless mode (roughly): we proxy input to flash, and flash renders into a buffer we provide it. In windowed mode, we create a native OS child window for flash and let it handle input and rendering directly. In this mode, without a way for flash to pass "unused" keys back to us, it will require some ugly hacks to steal hotkeys from it reliably. Most sites run flash in windowed mode, and for good reason - flash's performance sucks in windowless mode, and it cannot make use of hardware acceleration (IIRC). Since Adobe's NPAPI flash seems to be essentially in stability mode, it's unlikely this will be improved :( Now, in current multiprocess mode, we actually force flash to use windowless mode -- because support for windowed mode isn't finished yet (bug 923746). But the aforementioned performance issues mean that we'll probably remove that restriction once we support windowed mode in multiprocess.

Groxx 13y ago

Testing it out now, so far so good! I might make this my default profile, I would love not having rogue tabs freeze the entire system. It's very nearly my one remaining thing I prefer Chrome for, Firefox has really improved lately.

shmerl 13y ago

What about IPC embedding API? It already separates the UI from the heavy Gecko processing: https://wiki.mozilla.org/Embedding/IPCLiteAPI https://wiki.mozilla.org/Embedding/IPCLiteAPI I just hope Mozilla won't go extreme, and won't use a separate process for each tab like Chrome does. It produces memory bloat if you have many tabs open. While they say they'll mitigate memory issues, this should be balanced.

ksec 13y ago

I really wish all these could be speed up by us Kickstarting it or donating on it. It has taken far too long for e10s.

goggles99 13y ago

This is a terrible idea. There is no justifiable reason to do this. The reasons given are weak, this is just more over engineering that will add an enormous amount of complexity and add no real value. Lets look at the reasons given as to why they want to do this. >Performance. Most performance work at Mozilla over the last two years has focused on responsiveness of the browser. The goal is to reduce "jank"—those times when the browser seems to briefly freeze when loading a big page, typing in a form, or scrolling. You can do all of this with proper threading and task delegation. Putting things in separate processes will not magically make things better. The answer to "jank" is proper coding, not over engineering. Last time I checked there was the same "jank" in IE and Chrome even though they use MPs. >Security. Technically, sandboxing doesn’t require multiple processes. However, a sandbox that covered the current (single) Firefox process wouldn’t be very useful. Sandboxes are only able to prevent processes from performing actions that a well-behaved process would never do. Unfortunately, a well-behaved Firefox process (especially one with add-ons installed) needs access to much of the network and file system. This is BS. You could have three processes and have FireFox sandboxed completely. Main process runs in a low integrity mode which limits it's resource access to a single directory. Second process is a download delegation process (takes a file after it is downloaded and moves it to the requested location while also promoting it's integrity) running in normal integrity mode. Third process is a network communication delegate/proxy running in normal or possibly even low integrity. These two delegate processes I mentioned will still be needed for the MP Firefox so it is no more work to create them. >Stability This is the only true benefit, but it is of very little value. Firefox almost never crashes and when it does, the session restore brings you back to were you left off in seconds. Cons? More complexity means more bugs. This is a workaround for really fixing FireFox. I am going to have 150+ extra processes in my task manager now. More memory use. More context switches in the operating system eating up resources and causing more system latency and overall slowdown (context switches at the kernel level which will affect the whole OS).

goggles99 13y ago
LOL, I posted this same message on the blog comments and they deleted it. Nothing like censorship to stifle opposing opinions.