CPU usage is higher when Firefox is minimized

[NeilWaldhauer]

Using Firefox 45.9.0, with or without the new XUL.DLL from x3.7z, CPU usage on the default Firefox web page is low, in the few percent. When minimized, this usage jumps to 50-100% on the dual processor desktop computer, but to 99% on a slower single processor computer.

[lerdmann]

I can confirm that problem. What I can also observe:

1. if you minimize Firefox and then use TOP you will notice that thread 1 (the main GUI thread) and another thread are always in the "runnable" state
2. if you have Firefox running with a visible window, TOP still shows thread 1 to always be in the "runnable" state

That is really odd. If I start Thunderbird and have a look with TOP, all threads of Thunderbird will be in the "blocked" state.
It looks like there is something in Firefoxes main thread that is constantly executing without ever deliberately giving up its time slice (of course the OS will reschedule after some maximum timespan).
If Firefox is minimized this behaviour extends to yet another Firefox thread.

[lerdmann]

Even more strange: with the Firefox main window visible, after some time, all Firefox threads will eventually enter the "blocked" state. However with Firefox window minimized, the aforementioned behaviour persists with 2 threads being in the "runnable" state.

[SilvanScherrer]

hmm does that happen always? or only if certain websites are open? I just tried it with 5 open tabs, while one of those is slack. And I did not see this behavior.

[dspiatkowski]

On Tue, 17 Apr 2018 12:33:06 +0000 (UTC) Silvan Scherrer wrote: hmm does that happen always? or only if certain websites are open? I just tried it with 5 open tabs, while one of those is slack. And I did not see this behavior.

Curious indeed, but it does seem to partially match what I have been seeing here as well, I just never took this a step further like Lars did to try to understand what was going on with the threads. Specifically, what I noticed is the following: when FF starts eating up the CPU cycles and it happens to be the active window, minimizing it sometimes will cause the CPU cycles to go away. I attributed that to there existings browser logic which "shuts off" whatever page refresh/processing may be happening while the window has the focus. Now I did say "sometimes" because that does not always work. Oftentimes I will simply open an entirely blank NEW tab and then minimize the browser, which will usually cause the CPU spikes to drop. So, at best, pretty inconsistent. What is the expected behaviour when the following happens: 1) window is pushed to background 2) window is minimized

…

-Dariusz

[StevenLevine]

This behavior appears to be extension dependent. I have a number of test profiles and some exhibit the 100% utilization issue when minimized. I've not yet had time to track down which extension(s) trigger the behavior.

[lerdmann]

Then I can add that I only have 1 extension: "uBlock Origin".

[dryeo]

On 04/17/18 09:13 AM, lerdmann wrote: uBlock Origin

I think that is one that triggers high CPU usage. Dave

[lerdmann]

Disabling "uBlock Origin" does not make a bit of a difference.

[lerdmann]

I cannot see any dependency on open websites either. Even with no website opened at all (only an empty page) I can see this odd behaviour of threads that continue to be "runnable" when Firefox is minimized.

[lerdmann]

Update:
with only an empty tab open, only thread 1 of Firefox will be in "runnable" state on minimizing Firefox. Therefore I suspect that the second thread that used to be "runnable" on minimize deals with serving webpage content.

[NeilWaldhauer]

On another computer, I tried, again with the Mozilla Firefox Start Page. The CPU monitor on xCenter didn't show 100%, but TOP does show 100 % CPU for firefox, with only one thread at 100% and all others blocked. All extensions, Chatzilla, FireFTP, Password Exporter, UAControl are disabled.

[lerdmann]

If if minimize Firefox I can see in XCenter the 100 % CPU use "wandering" between the 8 cores that I have active.
If I open TOP is can see at least thread 1 being in the "running" state.

[dspiatkowski]

On Sat, 21 Apr 2018 07:41:34 -0700 lerdmann wrote: If if minimize Firefox I can see in XCenter the 100 % CPU use "wandering" between the 8 cores that I have active. If I open TOP is can see at least thread 1 being in the "running" state.

For what it's worth, this behaviour seems to have gotten worse with the latest GA1.1 release. Not sure if there is any co-relation between the two, but my overall CPU usage is now noticably higher. Basically, on a 5 core machine I am seeing a consistent 15-20% average (over the past 1 min - as reported by the 'CPU Monitor' utility) usage. When I view this in the 'MPCPU Mon' OS/2 utility, with the refresh of 150 ms I see an on-going CPU spike taking place across all cores. Having said that, the GA1.1 drop overall, while feeling a tad slower, does seem to be more stable. I noticed memory consumption seems to have slowed down, and while the overall steady CPU utilization is higher it no longer seems to increase as total runtime of the process increases. In the past the CPU utilization used to slowly climb over the hours FF was up and running, until after about 10-15 hrs (depending of course on the amount of usage) the CPU spikes became so consistently large that I needed to kill the process and re-start. Now, as far as the past 3 days of usage indicate, that is no longer so pronounced.

[StevenLevine]

I captured a couple of process dumps with firefox GA 1.1 minimized and got some initial clues. PMDF tells us that thread 1 is in al call gate

Analyzing Call Gate ...
is in a 32 bit call gate: 0148:00004ea8 OS2KRNL DOSSETFGND
Called by: %1fbf5a14 PMMERGE CheckLoseBoost + 50
Past end of segment: 00bf:0000f8d4

This is not good because PMMerge should not be doing this kind of thing while minimize.

A very rough dump of the stack, using a somewhat out of sync .sym file claims

%findsym %0013f01c

Finding from %0013f01c to %0013f11c by dword
13f02c: 0ddb112f = xpc::JSReporter::CollectReports + 22A17AF
13f038: 0de83390 = xpc::JSReporter::CollectReports + 2373A10
13f03c: 0ded758b = xpc::JSReporter::CollectReports + 23C7C0B
13f048: 0ded7544 = xpc::JSReporter::CollectReports + 23C7BC4
13f05c: 0de8352b = xpc::JSReporter::CollectReports + 2373BAB
13f068: 0dd0af00 = xpc::JSReporter::CollectReports + 21FB580
13f06c: 0de833b0 = xpc::JSReporter::CollectReports + 2373A30

This might imply that the JS engine is not aware that firefox is running minimized. I will be able to provide a more useful stack trace once I have a copy of xul.map.

Note that the best way to debug this is probably going to be with kernel debugger. Minimize firefox. Break in. Select firefox thread one and step out of the kernel code and figure out what the ring3 code is doing. Once you have a rough idea of where this is, you probably can continue with the VAC debugger.