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.

It has improved dramatically since then. I'm not saying it's perfect, but I think you should give it another shot instead of complaining about how bad it used to be.

I remember that phase, it was below-alpha quality. It's now okay, no fear to have, only some occasional hiccups like asynchronous errors (click somewhere at time T, click action triggered regarding the element at time T+x).

You can't use beta software and complain about stability issues.

What? You were going to switch browsers because you were having problems using a beta or nightly version? I have an idea... Use the release version!

Release has even worse memory issues, I had to go beta to get memory usage down and prevent crashes in the first place.

Memory issues? I have have never had any memory issues with Firefox and it's been almost crash free now for the last six releases.

It's 2016 now so maybe it's time to upgrade your box and it's 4 GB of RAM.

EDIT: How is Firefox eating up to 3Gb of RAM on your machine? I never seen mine go over 1.5GB and that's been after a week of not closing it (64-bit version/no Flash installed).

I've easily gotten it up to 4GB. Five windows, several tens of tabs per window. Webapps like GMail (2 instances of it), GCal (also 2), Facebook, Tweetdeck, Slack, etc. open all the time eat a ton of RAM, and just various complex websites/apps sitting open over time will often leak a bit.

I just restarted FF an hour or so ago, and haven't even had it reload most of the tabs that used to be open (FF restored them, they're just not loaded yet as I haven't tabbed to them), and I'm already at 1.5GB resident with probably 15 active/loaded tabs.

It doesn't sound like you are doing anything much different than me except I don't use Facebook. I normally keep my browser open for weeks at a time and never break 2GB unless hit some crap website. Addons?

Could be. I haven't tried disabling any of them to see if they're causing high mem usage. Good next step, thanks.

200 tabs split in 12 windows, each window seem to carry a big overhead. Btw, I said "2 to 5 GB of free RAM", so that means I have more than 4 GB total... pay a bit more attention before being pedantic.

I read your comments just fine but you weren't making sense but now you explained it. 200 tabs in 12 windows? Yeah, nobody cares your browser is crashing now. You can switch to Chrome and maybe it won't crash as much but it will use more memory.

Personally, I would reevaluate how you use browser.

> Btw, I'm not "memory constrained", I always have 2 to 5 GB free memory, but once the firefox process is over 1,5 GB then trouble begins, at 2 GB it's about to crash, and over that it can sometimes survive as large as 2,5 GB, but I've never seen it use more -- it always crashes before reaching 3 GB.

Was this for a 64-bit build of Firefox?

Yes, 64 bit beta. Took a a bit of digging to find it, but it was the first thing I checked once I began seeing this crashes. The only thing that fixed it was when it went back to the single process architecture.