Created attachment 230657 [details] Screenshot: an htop view of a thought-provokingly high number of firefox processes dom.ipc.processCount is 8 (the default) however, as far as I can tell: * many more than eight such processes may become apparent in e.g. htop(1) * if excesses are not apparent at start time, after Firefox completes its reopening of previous windows and tabs, then they may become apparent when (for example) I begin to load tabs that were reopened -- maybe only if no favicon is apparent before the click to load. about:support currently shows an isolated web content count: 13 – although I don't know whether this bears any relationship to dom.ipc.processCount – and htop shows a number greater than 13 for firefox processes matching: -isForBrowser At a glance, the number visible in htop _might_ equal the sum of the five types of remote process in about:support. Environment =========== % pkg info -x firefox firefox-95.0.2,2 % pkg -vv | grep -e url -e enabled url : "http://pkg0.pkt.freebsd.org/FreeBSD:14:amd64/latest", enabled : yes, url : "https://alpha.pkgbase.live/current/FreeBSD:14:amd64/latest", enabled : no, url : "file:///usr/local/poudriere/data/packages/main-default", enabled : yes, % freebsd-version -kru 14.0-CURRENT 14.0-CURRENT 14.0-CURRENT % uname -aKU FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #118 main-n251923-4bae154fe8c: Sat Dec 25 08:03:37 GMT 2021 root@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 1400045 1400045 % Early thoughts ============== Ultimately: this might be not a bug, or a bug upstream. For now: after observing symptoms for a few days, my gut feeling is that the behaviours might be specific to the (Tier-3) port to FreeBSD. Certainly: with the port to FreeBSD, it's relatively easy (compared to e.g. Linux) to view the number of firefox processes with utilities such as htop. Qualitatively: sometimes I do feel that recommended performance settings are no longer as effective as they were, say, a few weeks ago.
Created attachment 230658 [details] Screenshot: a Tree Style Tab view of various representations of non-loaded states > -- maybe only if no favicon is apparent before the click to load. Attached: a copy of my screenshot from <https://github.com/piroor/treestyletab/issues/2845#issuecomment-1000836106> I should not complicate this bug 260901, however it's worth noting (from <https://github.com/piroor/treestyletab/issues/2845#issuecomment-1000880498>): >> I'm getting duplication of tabs in recent days, difficult to >> diagnose, but I'm slowly gaining the impression that it occurs: >> >> * only if the tab is without a favicon when clicked for the >> first time (after the Firefox startup routine finishes >> opening previous windows and tabs). >> >> I have been unable to refine the bug to any particular extension, >> or combination of extensions. >> >> I began wondering whether the issue is with Firefox, then found my >> April 2021 issue 2880 involving duplication (closed, >> not a TST issue), then found this duplication-related issue >> #2845 with the Firefox-issue label. Note: duplication also occurs when extensions other than Tree Style Tab are in the sidebar and are used to load tabs. Now: * if there is _truly_ a performance-related bug involving an excess of processes * and if the excesses are a consequence of the duplication described above * is it possible that some combination of extensions triggers this bug 260901? On one hand: I do have an unusually large number of extensions enabled. On the other hand: I should not expect the design of (upstream) Firefox to allow any extension to cause loss of effectiveness of recommended performance settings.
Created attachment 234292 [details] Screenshot: 10 -isForBrowser content processes (In reply to Graham Perrin from comment #0) > … dom.ipc.processCount is 8 (the default) however, as far as I can tell: > > * many more than eight such processes may become apparent > in e.g. htop(1) In an effort to reduce the impact on performance, I reduced the number. Down from 8, it's now: dom.ipc.processCount 3 So far, touch wood, things feel better. At the time of writing I see: 10 (ten) -isForBrowser content processes in htop.
(In reply to Graham Perrin from comment #2) > In an effort to reduce the impact on performance, I reduced the number. > Down from 8, it's now: > > dom.ipc.processCount 3 I reduced the number to 1. Still, there arose an excessive number of -isForBrowser processes. ---- I'm now experimenting with: dom.ipc.processCount 3 fission.autostart false From <https://bugzilla.mozilla.org/show_bug.cgi?id=1596857#c2> (2019-11-15): > … Fission, because we will always create new processes for new domains, …
Tentatively: www/firefox works as intended, in that (as far as I can tell) the traditional wisdom of attempting to control performance in this way: about:preferences#general Performance ☐ Use recommended performance settings Content process limit – may be no longer effective, if Fission allows an unexpectedly large (and non-controllable) number of processes to have a negative impact on performance. <https://blog.mozilla.org/performance/tag/fission/> I'll seek advice elsewhere, with an assumption that there's an issue upstream.
(In reply to Graham Perrin from comment #4) <https://new.reddit.com/r/freebsd/comments/vah214/-/> I ran a poll, too few respondents for the result to have any meaning.
(In reply to Graham Perrin from comment #4) <https://phabricator.services.mozilla.com/D105055>, closed in 2021: * if fission is enabled, the content process limit is no longer exposed in the GUI at about:preferences
Created attachment 242553 [details] Screenshot: 2023-05-28, fission enabled, dom.ipc.processCount.webIsolated 4 (the default) (In reply to Graham Perrin from comment #2) > … an effort to reduce the impact on performance, … From <https://bugzilla.mozilla.org/show_bug.cgi?id=1742892#c12> (2021-12-07): > … can't limit the total number of content processes Fission will use, > but you can limit the number of content processes Fission will use > per site by setting the dom.ipc.processCount.webIsolated pref (the > default is 4). … 𠄣– and: > … I think the memory overhead of each content process is only about > 20 KB, so there is really not much benefit to decreasing > dom.ipc.processCount.webIsolated. I don't intend to reopen this bug report, but I see nothing like 20 KB in the attached screenshot.