Hacker News Reader

Comment by sp332 | Hacker News Reader

FF doesn't use process per tab. It will use one process for chrome and one for all the content rendering for all tabs.

It will in the future from what I understand. You can enable it right now in nightly.

You can set a certain max number of processes. I don't think there's a way to explicitly do process-per-tab or process-per-domain.

There isn't. It is planned to add an algorithm for grouping tabs into processes and dynamically adding/removing content processes, but that's low priority right now, because the current focus lies on getting the single content process e10s ready for the release channel.

More info in the e10s-multi bug and its dependencies:

https://bugzilla.mozilla.org/showdependencytree.cgi?id=e10s-...

(also a nice way to look for known issues that might affect you if you're interested in trying out e10s-multi)

What benefits does that provide over 1 process per tab?

Edit: I misread your comment. As RussianCow mentioned, it's to keep resource usage under control.

The main advantage is that browser chrome is still responsive during rendering. You can switch tabs, open menus, resize windows etc. Also, rendering is a little faster since you don't have to interrupt it constantly to keep the UI responsive. And if the content process dies, all your tabs are still "open" and you can reload the content.

I think the parent was asking about the advantage over Chrome's model of having one process per tab, not over the current single-process model.

Chrome doesn't have a model of one process per tab, fwiw.

It has a model of one process per tab until you have enough tabs, then tabs start sharing processes based on various heuristics.

Shot in the dark here, but Chrome was developed back when it was common to have a single core CPU without any hyper-threading. An easy way to balance load is this scenario is just make a bunch of processes and have the OS do all the heavy lifting in regards to scheduling as everything has to share that one thread. You also get the benefit of bad processes dying without taking down the entire browser. At the time Chrome was coming around, browser stability was a larger issue than it is today.

Now that everyone has a multi-core cpu, it makes more sense to not really worry too much about scheduling. The OS will just move stuff off a busy core and onto a less busy core dynamically. So why not just separate the UI front end from the rendering and call it a day? Why bother with so many processes when you have cpu cores to spare? The UI and renderer will run in their own cores when they get too cpu hungry. Also, if the renderer crashes, no biggie, the UI just re-renders everything.

But if you have a tab with heavy JS, that's going to slow down all the other content as well since they must share a CPU. If each tab got its own process, the heavy one could get its own core. Same if one crashes, it takes all the others down.

Maybe they can't do multi-process because of legacy code concerns.

Also, you gain memory savings as you aren't spawning all those processes which have redundant libraries and such loaded.

I've read many times that Chrome is a heavy resource consumer due to their one-process-per-tab architecture. Maybe others can say more ...

I've heard the 1:1 mapping was only true at first, they tried to merge processes by domain IIRC.

Presumably, you don't have the overhead of running a separate process for each tab, which adds up quickly when you have 50+ tabs open.

Significantly lower memory usage.

None, really. Process per tab is the end goal - this is just a step along the way.

Reply on news.ycombinator.com