Jump to content
MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. ×

Force "multiprocess mode" in FF 52


Recommended Posts

"I was under the impression this pref would only work with FF53 (or Basilisk 55)
user_pref("browser.tabs.remote.separateFileUriProcess", true); // add manually"

Probably so. I am just testing, and have not yet tried loading file://s. I will soon test with tiddywiki and see.

True, I have two nvidia quadro in this setup, so juice there is -but I tried in a lesser VM setup, and it ain't bad at all, compared to the status quo before learning about browser.tabs.remote.force-enable (thanks @Mathwiz).

But I also have plenty confidence on the skills and foresight of @roytam1.

PS: since my 15s I have cut my hair (myself, with sizers) cherokee (or something like that) style, so I have practice with using black stuff to cover the hairless-spots I've been leaving in my skull. Now I have to find some greyish stuff to do the trick    :P

Edited by dmiranda
  • Like 1
Link to comment
Share on other sites


Just for the fun of it :P, and intrigued by this latest "revival' of the e10s/Serpent topic, I went ahead and enabled e10s in my latest St52 [v52.9.0 (2021-07-16) (32-bit)] working profile, having it properly backed-up beforehand... ;)

This is an old, 2008 era, Vista SP2 32-bit laptop, with a Core2Duo CPU, an integrated GPU (with no h264 H/W decoding support) and a blacklisted, vendor customised, gfx driver, that can't be updated any further; in essence, an under-resourced PC by today's standards... :(

I witnessed no crashes at all, but the expected increase in RAM consumption:

aqrZsqj.jpg

I don't frequent facebook, instagram, twitter, tiktok, discord, etc. (the main villains :realmad: ) and I only occasionally visit "GoogleTube" (because it's Google's, not yours... :angry: ), so the browser remained responsive on most sites I use :) ...

HOWEVER, as part of my daily workflow, I must have several GitHub tabs open in Serpent 52; GitHub (and recently GitLab) is unusable in UXP browsers, unless JustOff's GitHub-WebComponents-Polyfill legacy extension is installed: 

https://github.com/JustOff/github-wc-polyfill/releases

But said extension IS NOT electrolysis (e10s) compatible, so, sadly :(, I'll have to return to my single-process profile to continue using it on GitHub...
Happy experimenting to the rest of you ;), I'll be still keeping an eye on this thread (though in a silent manner, I'm afraid) ... :rolleyes:

Best wishes :)

Edited by VistaLover
  • Like 2
Link to comment
Share on other sites

On 7/19/2021 at 1:01 PM, XPerceniol said:

Am I right in saying Basilisk 55 *was* actually based on FF53, and not really/truly FF55?

As @VistaLover noted, Basilisk 55 (aka Moebius) was forked from an alpha version of FF 53. My understanding is that the "55" came from the fact that some changes were back-ported from FF 54 and FF 55 before MCP gave up on Moebius and re-forked Basilisk from FF 52.6. (Sort of like what ArcticFox and @roytam1 have been doing with NM 27 lately ;))

Anyway, as an (albeit early) FF 53 fork, Serpent 55 is probably the best XP platform for e10s multi-process mode, although memory usage does get pretty large pretty quickly! (The second-best XP platform for e10s would likely be "stock" FF 52.9.) I've been using e10s with St55 for a couple of years now, without noticeable ill effects (other than memory usage), although I keep a "single-process mode" profile available, in case I need to use those incompatible browser extensions (notably Classic Add-Ons Archive).

On 7/19/2021 at 6:37 PM, ArcticFoxie said:

@XPerceniol - you cited in one of the 360Chrome threads that multi-process (several .exe's in the Windows Task Manager) is one of the things that you do not like about Chrome-based browsers.

So I must admit, I'm a bit confused that you are attempting to bring multi-process to FF-based browsers when that support by its developers never matured anywhere near the level of Chrome development (from my understanding).

I can't speak for @XPerceniol, but speaking for myself, one advantage of multi-process mode in the FF platform is the ability to limit the number of processes to something reasonable. In "straight" FF, you get one process, period. That obviously isn't enough for many modern sites. But in Chrome, AIUI, you get a separate process for each tab of each window - overkill IMO. E10s lets you choose a reasonable "middle ground" based on how you use your browser and how much RAM your system has.

  • Like 1
Link to comment
Share on other sites

On 7/25/2021 at 6:51 PM, Mathwiz said:

But in Chrome, AIUI, you get a separate process for each tab of each window - overkill IMO. E10s lets you choose a reasonable "middle ground" based on how you use your browser and how much RAM your system has.

It's not that simple in Chrome.

I don't know the "algorithm" and can't really say as it concernms me too much, but it really cannot be "watered down" to "a separate process for each tab of each window".

Maybe I'll research it one of these days, but other priorities kinda take precedence at the moment.

I'm showing 12 processes for four windows with two tabs each.

Drop down to two windows with two tabs each and I'm at 8 processes.

Move the second window's two tabs into the first window and close that second window still has me at 8 processes.

Drop down to only one tab in that one window and I'm at 5 processes.

Open a second window and open 15 tabs so now I have one window with one tab and a second window with 15 tabs and I'm at 23 processes.

Open a third window and open 25 tabs and I'm at 52 processes.

Open a fourth window and open 49 tabs and I'm at 86 processes.

Return to the third window and open 24 more tabs and I'm still at 86 processes.

Return to the second window and open 24 more tabs and I'm still at 86 processes.

 

So that kinda tells me that Chrome chooses its own "middle ground" and that Firefox just isn't "smart enough" to choose its own "middle ground" so the developers opted to create a scheme where the "user" sets that "middle ground".

That probably works for most MSFN FF users, but I'm betting that the "average" FF user probably only "cripples" their FF by trying to set that "middle ground".

But anywhoo...

 

Link to comment
Share on other sites

On 7/21/2021 at 3:15 PM, XPerceniol said:

I was under the impression this pref would only work with FF53 (or Basilisk 55)
user_pref("browser.tabs.remote.separateFileUriProcess", true); // add manually

Be it that it treats a file as a normal tab, be it that the option is "hidden" (you gotta create it the pref in about:config) basilisk52 treats a file as a different process.

As of now, my user.js prefs are (auto means that user.js establish the pref without user action, set means that user has to set it manually in about:config, add means that user has to create it in about:config, review means that I'm not sure about it yet):

// MULTIPROCESS
user_pref("browser.tabs.remote.force-enable", true); // set
user_pref("browser.tabs.remote.autostart", true); // auto
user_pref("browser.tabs.remote.separateFileUriProcess", true); // add
user_pref("dom.ipc.processCount", 4); // set
user_pref("dom.ipc.process.webLargeAllocation", 4); // set
user_pref("extensions.e10sBlocksEnabling", false); // set
user_pref("extensions.e10sMultiBlockedByAddons", false); // add
//user_pref("browser.tabs.remote.autostart.2",); // reset if created

If your setup has the juice for it:

// ACCELERATION AND GRAPHICS
user_pref("layers.acceleration.force-enabled", true); // add
user_pref("layers.force-active", true); // set
user_pref("layers.acceleration.enabled", true); // default
user_pref("layers.async-pan-zoom.enabled", true); // default
user_pref("layers.offmainthreadcomposition.async-animations", true); // default
user_pref("layers.offmainthreadcomposition.enabled", true); // add
user_pref("layers.async-video.enabled", true); // add
user_pref("html5.offmainthread", true); // default
user_pref("layout.frame_rate.precise", true); // set review
user_pref("gfx.direct2d.disabled", false); // default
user_pref("gfx.font_rendering.directwrite.force-enabled", true); // set
 

Edited by dmiranda
Link to comment
Share on other sites

On 7/28/2021 at 8:15 AM, ArcticFoxie said:

It's not that simple in Chrome.

I don't know the "algorithm" and can't really say as it concernms me too much, but it really cannot be "watered down" to "a separate process for each tab of each window".

Maybe I'll research it one of these days, but other priorities kinda take precedence at the moment.

I'm showing 12 processes for four windows with two tabs each.

Drop down to two windows with two tabs each and I'm at 8 processes.

Move the second window's two tabs into the first window and close that second window still has me at 8 processes.

Drop down to only one tab in that one window and I'm at 5 processes.

Open a second window and open 15 tabs so now I have one window with one tab and a second window with 15 tabs and I'm at 23 processes.

Open a third window and open 25 tabs and I'm at 52 processes.

Open a fourth window and open 49 tabs and I'm at 86 processes.

Return to the third window and open 24 more tabs and I'm still at 86 processes.

Return to the second window and open 24 more tabs and I'm still at 86 processes.

 

So that kinda tells me that Chrome chooses its own "middle ground" and that Firefox just isn't "smart enough" to choose its own "middle ground" so the developers opted to create a scheme where the "user" sets that "middle ground".

That probably works for most MSFN FF users, but I'm betting that the "average" FF user probably only "cripples" their FF by trying to set that "middle ground".

But anywhoo...

In every example you cited except the last two, there were more than "one process for each tab of each window," by a minimum of four processes! That is not a "middle ground" between one process, total (FF w/o e10s); and one process for each tab of each window - it actually means Chrome is more of a process hog than I thought (at least until you hit the apparent cap of 86(!) processes).

If Chrome were "intelligently" sharing processes as the total number of tabs increased, we would expect to have fewer processes than tabs, not more processes than tabs. But you didn't see that until you got up to 90+ tabs!

Link to comment
Share on other sites

  • 1 month later...
On 7/20/2021 at 12:14 PM, XPerceniol said:

..user_pref("dom.ipc.processHangMonitor", true);

 

 

 

See https://www.reddit.com/r/firefox/comments/ct0suf/any_way_to_disable_the_browser_pausing_with_a_web/app.support.e10sAccessibilityUrl

Also, now testing (after seeing your edit)

user_pref("app.support.e10sAccessibilityUrl","127.0.0.1"); // set

user_pref("app.support.baseURL","127.0.0.1"); // set

I may do the same for most mozilla.org references

Edited by dmiranda
  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    No registered users viewing this page.


×
×
  • Create New...