Jump to content

Force "multiprocess mode" in FF 52


Recommended Posts

I've put browser.tabs.remote.force-enable back in and set it to "true" and now it's working!
I have two processes in Task Manager.
:thumbup
I don't know what the problem was before, but thanks everyone for all the advice!
All my add-ons still seem to be OK, no error messages anyway.
:yes:

Link to comment
Share on other sites


1 hour ago, Mathwiz said:

Note: that pref appears to to have no effect in St 55. I always get 2 processes on XP and 3 on Win 7, regardless of how it's set.

I am still on the 2019-01-19 (32-bit) build of Serpent 55.0.0 under Vista SP2 x86, and I could NOT reproduce what you reported :dubbio:; I set 

browser.tabs.remote.autostart;true (default was false)
dom.ipc.processCount;4 (default was 1)

restarted the browser and with 21 tabs open (17 pinned, 4 normal, all loaded) I do have 5 basilisk.exe processes in TM:

GT01dvR.jpg

?

Link to comment
Share on other sites

17 hours ago, Mathwiz said:

Haven't tried it with FF or St 52 on XP yet. I'll do that tomorrow if I have time.

  •  
3 hours ago, Mathwiz said:

Edit: I just confirmed this on my own copy of FF 52. If you don't have browser.tabs.remote.force-enable set to true, FF won't start e10s on WinXP.

And it works the same way in St 52: e10s is disabled on WinXP unless you force it (edit) although the about:support message is different:

Quote

0/1 (Disabled forcibly)

So naturally I had to try on Win 7, and sure enough, it's disabled there too, unless you force it!

Methinks MCP slipped some code into St 52 that disables e10s unless forced.

St 55, though, lets you enable it the "official" way - even on WinXP.

So in summary:

  • On FF 52.9, e10s is disabled on WinXP (unless forced); can be enabled on other OSes
  • On St 55, e10s can be enabled on all OSes without forcing
  • On St 52, e10s is disabled on all OSes, unless forced.
Edited by Mathwiz
Link to comment
Share on other sites

1 hour ago, VistaLover said:

I am still on the 2019-01-19 (32-bit) build of Serpent 55.0.0 under Vista SP2 x86, and I could NOT reproduce what you reported :dubbio:; I set 

browser.tabs.remote.autostart;true (default was false)
dom.ipc.processCount;4 (default was 1)

restarted the browser and with 21 tabs open (17 pinned, 4 normal, all loaded) I do have 5 basilisk.exe processes in TM

Strange; it now seems to be working for me too, at least on WinXP. (I'm using the 2019-04-05 build of Serpent 55, in case that makes a difference.) I set dom.ipc.processCount to 2 and with two tabs, sure enough; I have 3 processes now. No idea what I did wrong last time.

Its behavior on Win 7 is puzzling. I always have 3 processes even though dom.ipc.processCount is set to the default of 1. If I set it to 2 will I get 4 processes? I'll investigate that further tonight after I get home.

Link to comment
Share on other sites

1 hour ago, Mathwiz said:
  •  

And it works the same way in St 52: e10s is disabled on WinXP unless you force it (edit) although the about:support message is different:

So naturally I had to try on Win 7, and sure enough, it's disabled there too, unless you force it!

Methinks MCP slipped some code into St 52 that disables e10s unless forced.

St 55, though, lets you enable it the "official" way - even on WinXP.

So in summary:

  • On FF 52.9, e10s is disabled on WinXP (unless forced); can be enabled on other OSes
  • On St 55, e10s can be enabled on all OSes without forcing
  • On St 52, e10s is disabled on all OSes, unless forced.

Could this be because 52.9.0/1 is an ESR version?
IIRC some things are disabled by default on ESR versions, but the code is still there and can be re-enabled (serviceworkers is another example).
:dubbio:

Link to comment
Share on other sites

Well, there is a string pref called app.update.channel. In FF ESR builds, it's set to esr. In "regular" FF builds, it's set to release (I think). In @roytam1's Serpent builds, it's set to default.

Note: it doesn't show as boldface in about:config (unless you change the default value); I'm just using bold here to indicate literal values.

Originally the code blocking e10s on XP only applied to release builds, but our experience indicates e10s is now blocked in esr builds too.

To see whether the block applies to default builds, I changed app.update.channel from esr to default and restarted FF 52. Unfortunately, about:support still indicated 0/1 (Windows XP). So apparently the code was changed at some point to block e10s on XP in all FF builds.

My guess is that the code was changed after Basilisk 55 was forked from FF 53, which would have been around the time FF 52.1 ESR was released. I distinctly remember having two firefox.exe processes through several updates of FF 52.x ESR, but I don't remember exactly which version that stopped with.

That doesn't explain Serpent 52 though. Basilisk (Serpent) was forked from FF 52, so it would have inherited the same code; so one would expect it to work like either Serpent 55 (where it always works) or FF 52 (where it's only blocked in WinXP). But since MCP eventually intends to remove e10s from Basilisk entirely, I'm guessing that somewhere along the line they changed the code to block e10s entirely unless forced.

Edited by Mathwiz
Link to comment
Share on other sites

Q:

7 hours ago, Mathwiz said:

I always have 3 processes even though dom.ipc.processCount is set to the default of 1. If I set it to 2 will I get 4 processes?

A: Yep! Apparently there's always one "extra" process when using Serpent 55 on my Win 7 system at home.

Edit: Note that this only happens with Serpent 55. Serpent 52 always gives 2 processes when dom.ipc.processCount is 1, and 3 when it is 2; regardless of OS.

BTW, browser performance seems to have improved a lot with that simple change.

Edited by Mathwiz
Link to comment
Share on other sites

I enabled this with FF 52 in XP x64 a while back and I started fiddling with the settings mentioned in this thread.

I regret it.  Now it's not working anymore.  I'll have to load up a ghost backup of my Firefox preferences to see what changed.

Link to comment
Share on other sites

Usually an original PC with Windows XP has a low amount of RAM.
And using the Swap always with the original HD is inefficient.
Better to use browsers that consume little RAM.
The single process certainly consumes less RAM than the multiprocess.
It would be interesting to check if with your Chrome-based browsers it is possible to force the single process without crashing:

https://peter.sh/experiments/chromium-command-line-switches/

--single-process

Related:

--process-per-site 

--process-per-tab

Link to comment
Share on other sites

13 hours ago, mockingbird said:

I enabled this with FF 52 in XP x64 a while back and I started fiddling with the settings mentioned in this thread.

I regret it.  Now it's not working anymore.  I'll have to load up a ghost backup of my Firefox preferences to see what changed.

Fixed it.  When I re-entered the boolean key, I put in browser.tabs.remote.force-enabled.

It should be browser.tabs.remote.force-enable without the 'd' at the end.

Link to comment
Share on other sites

Glad you fixed it @mockingbird!

Having assessed things for a day or two, I can report that the performance of Firefox 52.9.1 ESR on my system is now vastly improved since I finally managed to enable multiple processes.
On script-heavy sites like Facebook and YouTube, it was always quite slow and hesitant loading and updating pages, with scrolling being jerky and inline Facebook videos stopping and starting. Now it's much faster and smoother, in fact I would say it's pretty much as good now as the "latest and greatest" 64 bit Firefox 66 on Windows 10!
It is now a bit of a RAM hog, it's sometimes using nearly 1GB of RAM with two processes running, but as I only very rarely use it with loads of other stuff running as well, it's not a problem for me, although it might be if you have less that 3GB of accessible RAM.
I've not had any stability problems (touch wood!) and all my add-ons seem to be performing normally, despite me getting an add-on compatibility warning when I first tried the tweak.
I have dom.ipc.processCount set to 4.
All in all, I would personally well recommend doing this tweak.
YMMV of course, but it's definitely been a great performance improvement on my system!
:yes:

Edited by Dave-H
Link to comment
Share on other sites

Some more background to the story...

As many of you will remember, Firefox 51.0.1 was the last stable release officially supported on both XP and Vista; after that, the Fx users on said OSes were forcibly migrated to the FxESR 52 channel (it starts with 52.0esr build; but I can't recollect precisely at which exact esr version the migration was performed; it might've have been 52.0.1esr or 52.0.2esr etc.).

Though not officially supported on XP/Vista, all three stable builds 52.0, 52.0.1, 52.0.2 will install, launch and run under those OSes; many users at the time (including myself) chose to manually install a stable 52 flavour, for the duration it was being current; of course, one could not go past 52.0.2 in the release update channel, since 53.0.x wouldn't install/run under XP/Vista. Several XP+Vista users were left stranded on one of the stable 52.0.x versions and, via telemetry, Mozilla were made aware; sometime during the middle of the 52esr support cycle, Mozilla decided to first migrate those users to a pseudo 52.0.3 stable release, in essence simply changing them to the esr update channel (where Mozilla decreed they should've been in the first place), and that would then invoke an automatic update to the then current 52esr release...

FxESR 52 codebase is pretty much derived from the stable 52.0 codebase, so yes, the Windows XP "checking" code with regards to e10s is there, too... ICBB to check for relevant Bugzilla bugs, but if memory serves me right, blocking e10s on XP had to do with conflicts when graphics hardware acceleration (via D3D9) was ON in Firefox (about:support -> Graphics -> Features: Compositing); whether it is enabled by default or not has to do with your gfx card (and whether its driver is at its most updated version); I can't test this myself on XP, but in theory, if you manually disable gfx acceleration (Options -> Advanced -> General -> Browsing -> (untick) "Use hardware acceleration when available" and then RESTART the browser!), you should ( :dubbio:) be able to activate e10s under XP the standard way (i.e. without "force-enabling" it).

Firefox 53.0.x was never meant to run on XP/Vista (HINT: It can be made to run on Vista if you "install" the zip package and then patch the main executable so that the subsystem version is lowered to 6.0 from 6.1; system patented decoders via WMF are inaccessible though, because 53.0 doesn't check for Vista's WMF implementation, which is slightly different to Win7's); so the Mozilla devs had already removed (another case of code clean-up) the XP/Vista checks; since Basilisk/moebius (ergo Serpent 55.0.0) was forked from a pre-53.0 codebase, that's the reason why e10s on St55 on XP can be activated the "standard" way (you don't get the "0/1 (Windows XP)" block).

Basilisk/UXP (ergo Serpent 52.9.0) has had additional roadblocks put in place by Moonchild Productions to thwart multiprocess, as it's a feature they oppose to (and their stance has been explained in detail in their forum); that's the reason why trying to enable it by simply toggling browser.tabs.remote.autostart to true (and restarting) will get you the "0/1 (Disabled forcibly)" block; also, since Bk52 is not meant to run on XP, my educated guess is that MCP have already removed the e10s WinXP "checking" code in their forked (from 52.6.0esr) tree; again, lazy to check their code in order to verify this assumption... ;) As much of the e10s code is still there in Bk52 (but planned to be gutted anyway in the near future), force-enabling e10s in current St52 should work!
BEWARE: Pale Moon 28/UXP (New Moon 28) also comes with the pref browser.tabs.remote;false ; in contrast to St52, practically most of the underlying e10s code has been removed, so NEVER toggle that pref to true; you'll end up with an unusable browser and profile corruption!

On 5/9/2019 at 8:46 PM, Mathwiz said:

Its behavior on Win 7 is puzzling. I always have 3 processes even though dom.ipc.processCount is set to the default of 1. If I set it to 2 will I get 4 processes?

22 hours ago, Mathwiz said:

A: Yep! Apparently there's always one "extra" process when using Serpent 55 on my Win 7 system at home.

Edit: Note that this only happens with Serpent 55. Serpent 52 always gives 2 processes when dom.ipc.processCount is 1, and 3 when it is 2; regardless of OS

In Firefox 53.0+ and on Win7+, an additional process is spawned when e10s has been activated: this is the GPU_PROCESS (about:support -> Graphics -> GPU_PROCESS); this requires the Win7 version of D3D11 and, again, your installed gfx card has to be compatible...

A fourth (if ipc.processCount;1) process can be spawned if the pref browser.tabs.remote.separateFileUriProcess;false is toggled to true...

What is true for Fx 53.0 should also apply to St55 under Win7!

23 hours ago, Mathwiz said:

Well, there is a string pref called app.update.channel. In FF ESR builds, it's set to esr. In "regular" FF builds, it's set to release

23 hours ago, Mathwiz said:

To see whether the block applies to default builds, I changed app.update.channel from esr to default and restarted FF 52.

Simply changing the value of the app.update.channel pref doesn't change already installed code (an installed esr branch build can't be magically turned into a stable branch one)! It only has two effects:

1. Change the reported channel in the "about:support -> Application Basics -> Update Channel" section (BTW, this is absent in St52).
2. Make the already installed build check for updates in the modified (if exists) update channel; while this "hack" could be used in Firefox versions some years ago to easily change channels, now it does not work for that purpose; Mozilla devs have implemented security checks in the existing updater.exe binary; each update branch has a different binary with different file hashes, so even in the event an update (in the "new" channel) is found (in the form of a *.partial.mar or *.complete.mar file), the update won't be installed by the previous (belonging to a different channel) updater.exe binary. The proper way to change update channel is by manually over-installing a build belonging to the desired channel; do note that changing update channels causes (possibly) irreversible effects to the previously used browser profile...

18 hours ago, mockingbird said:

I regret it.  Now it's not working anymore.

Forcing multiprocess on unsupported platforms and configurations always comes with inherent danger; it is said so in the link I posted previously:

https://wiki.mozilla.org/Electrolysis#Force_Enable

Quote

This is not encouraged, use it at your own risk!

So people, ALWAYS MAKE A BACK UP OF YOUR EXISTING BROWSER PROFILE prior to venturing into uncharted waters! ;)

Edited by VistaLover
Link to comment
Share on other sites

22 hours ago, Mathwiz said:

Browser performance seems to have improved a lot with that simple change.

 

5 hours ago, Sampei.Nihira said:

Can you explain better?

It's quite a bit more responsive. With dom.ipc.processCount set to 1, the active tab tended to "hang" when another tab was refreshing in the background. When set to two, it didn't seem to hang.

This was on a Win 7 64-bit system (though it was the 32-bit version of Serpent 55). I don't know if it will improve as much with 32-bit Win XP as it did with 64-bit Win 7, but it seems OK on my Win XP VM even with dom.ipc.processCount set to 1. So you should probably just leave it at 1 unless you're having "hangs" like I was. There's probably not much point in setting it higher than 3 unless you have a 64-bit OS with beaucoup RAM.

4 hours ago, Dave-H said:

It is now a bit of a RAM hog, it's sometimes using nearly 1GB of RAM with two processes running, but as I only very rarely use it with loads of other stuff running as well, it's not a problem for me

I sort of expect RAM usage to be higher with more processes, but as long as you have enough RAM, I'm hoping you'll find FF / Serpent to be more responsive.

4 hours ago, Dave-H said:

On script-heavy sites like Facebook and YouTube, it was always quite slow and hesitant loading and updating pages, with scrolling being jerky and inline Facebook videos stopping and starting. Now it's much faster and smoother

Glad to hear it. That's what e10s was supposed to do.

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
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...