firefox 110.0.1 excessive cpu usage
Categories
(Core :: Performance, defect)
Tracking
()
People
(Reporter: reikred, Unassigned)
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:104.0) Gecko/20100101 Firefox/104.0
Steps to reproduce:
I updated firefox from 103.0.2 to 104.0 on linux desktop (ubuntu 21.04)
Actual results:
I tried 104.0 on multiple large profiles. On all of them, the main process is using a lot more cpu than before, and it persists over 30min after loading , so far.
According to about
Expected results:
In 103.0.2, cpu usage quiets down quickly after loading a profile. The about:performance tab often has the addon called tab counter@daaweseomp as the highest using "tab", but not sure how significant that is.
The colon character cut something off in the above. Let me try again.
In 103.0.2, cpu usage quiets down quickly after loading a profile. The about(colon)performance tab often has the addon called tab counter@daaweseomp as the highest using "tab", but not sure how significant that is.
|
||
Comment 2•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Performance' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Comment 3•3 years ago
|
||
linux desktop (ubuntu 21.04)
You are using an ancient, outdated, unsupported (for 7 months) version full of security vulnerabilities
I disabled the addon tabcounter@daaweseomp, and cpu usage is still high among other addons. Seems like it is not one specific addon, but the entire addon system that has gone bad.
Sigh. This is why I backup all my firefox profiles before I try a new version. With regularity, performance goes completely down the drain when a new version is introduced, and there is NOTHING in the release notes that indicates what might be the culprit. Then randomly, a couple (or more) versions later, the problem has been fixed, but I'll be damned if there is ever an explanation of what happened. This must have happened a dozen times during the lifetime of firefox. At some point I had to switch to waterfox for many months because firefox was so broken. It is a total pain. Please do heavy duty performance testing, also with addons, before you release new versions.
(In reply to Andre Klapper from comment #3)
linux desktop (ubuntu 21.04)
You are using an ancient, outdated, unsupported (for 7 months) version full of security vulnerabilities
Oh stop it. The problem is with Firefox,. not with Ubunto 21.04. And you know it. Stop burdening bug reporters with spurios upgrade requests.
|
||
Comment 6•2 years ago
|
||
Please capture a profile with http://profiler.firefox.com/ , upload it and share the link here. This will allow us to see the cause of the high CPU usage directly.
I was foolish enough to get started on the ub 21.04 to 22.04 upgrade that was requested. I'll run the profiler once the system has stabilized in good order. It may take several days.
(In reply to Bas Schouten (:bas.schouten) from comment #6)
Please capture a profile with http://profiler.firefox.com/ , upload it and share the link here. This will allow us to see the cause of the high CPU usage directly.
I am now able to run the profiler after much trouble/delay in upgrading to ubuntu 22.04. Here is the profile.
https://share.firefox.dev/3KLEqNS
I'm now running firefox-110.0.1 but the CPU usage problem is still the same. Before I go about filing another bug against 110.0.1 , can you please take a look at the profile. If there is a way to reas-assign the bug to version 110.0.1 , that would be great, too.
I added :bas:schouten to the cc: list,. I was hoping he would see the profile I provided in response to his question.
|
||
Comment 10•2 years ago
|
||
Many of your open windows seem to be running some animation. Could you capture another profile with the following changes:
- In the profiler panel, go to "Edit Settings..." and turn off Screenshots in the profiler settings.
- When you share / upload the profile, include hidden threads. This will include the Compositor thread, which may have some more information about which animation is running.
Thanks!
|
Reporter | |
Comment 11•2 years ago
|
||
(In reply to Markus Stange [:mstange] from comment #10)
Many of your open windows seem to be running some animation. Could you capture another profile with the following changes:
- In the profiler panel, go to "Edit Settings..." and turn off Screenshots in the profiler settings.
- When you share / upload the profile, include hidden threads. This will include the Compositor thread, which may have some more information about which animation is running.
Thanks!
Here is the profile request. I hope I did it correctly, please let me know.
|
|
Reporter | |
Comment 12•2 years ago
|
||
I added an information request for :mstange, maybe I should have done that earlier. I'm not an export on bugzilla protocol ;-).
PS: I'm not aware of running any animation.
|
|
||
Comment 13•2 years ago
|
||
Hmm, so we can see that it's a transform animation, and sometimes also an opacity animation. Do you see anything animating visually? Maybe a loading throbber?
Florian, do you remember if there's a way to find out more about these animations? Do we have a bug filed on adding main thread animation markers for animations which are already running when the profiler is started (and which don't complete before the profiler is stopped)?
|
||
Comment 14•2 years ago
|
||
(In reply to Markus Stange [:mstange] from comment #13)
Hmm, so we can see that it's a transform animation, and sometimes also an opacity animation. Do you see anything animating visually? Maybe a loading throbber?
Florian, do you remember if there's a way to find out more about these animations?
You have the Process ID of the animation in the "SamplerAnimation" markers of the compositor thread. There are 28 animations being sampled at 60Hz. Except for 2 animations (1 transform, 2 opacity) happening in content processes, all the others are transform animations in the parent process.
I would be tempted to guess the transform animations in the parent are tab loading animations for tabs that never finish loading (so this bug would be a rather extreme duplicate of bug 1503259, and bug 1812019 would hopefully help), but in that case we should have "CSS animation iteration" markers on the main thread every 1.1s, which we don't have.
Do we have a bug filed on adding main thread animation markers for animations which are already running when the profiler is started (and which don't complete before the profiler is stopped)?
I remember we discussed this for refresh observer markers (and maybe also animation markers), but I don't remember filing a bug for it.
|
|
||
Comment 15•2 years ago
|
||
(In reply to Markus Stange [:mstange] from comment #13)
Do you see anything animating visually? Maybe a loading throbber?
Oh, I guess you answered that question here:
(In reply to reikred from comment #12)
PS: I'm not aware of running any animation.
|
|
||
Comment 16•2 years ago
|
||
(In reply to Florian Quèze [:florian] from comment #14)
I would be tempted to guess the transform animations in the parent are tab loading animations for tabs that never finish loading (so this bug would be a rather extreme duplicate of bug 1503259, and bug 1812019 would hopefully help), but in that case we should have "CSS animation iteration" markers on the main thread every 1.1s, which we don't have.
Hmm, interesting!
I wonder what it could be, then? Maybe something that an add-on puts in the sidebar? Or some kind of animated theme?
|
|
Reporter | |
Comment 17•2 years ago
|
||
(In reply to Markus Stange [:mstange] from comment #16)
Based on reading the recent comments above, I just developed a hunch backed by a semi-plausible theory: Could this whole thing be related to running a color.firefox.com theme that gets into an infinite loop ping-ponging with the tabs loading (or not loading)? Specifically 'm running
which among other things changes the color of the active tab. The above color scheme does NOT produce the color change in 110.0.1 (but worked fine in 103.2). When I looked at the tab containing the above link [1], there is (in 110.0.1) a popup subwindow that asks "Do you want to apply this custom theme"[2]. If I click "Yep", the color scheme still does not work, , and CPU stays high, but I can't help but wonder if firefox got itself into a sort of deadlocked infinite loop because of not having an answer for [2] when firefox started.
Does this give any or you any ideas what the underlying mechanism of the bug is? Also keep in mind that bug started in 104.0 and we are now observing it in 110.0.1.
|
|
Reporter | |
Comment 18•2 years ago
|
||
(In reply to reikred from comment #17)
On 2nd thought I am not all certain about what I wrote above. I did a "revert all" to undo any color.firefox.com settings, and restarted firefox. Made no difference to CPU usage.
|
|
Reporter | |
Comment 19•2 years ago
|
||
I found one way to make the problem go away:
Create integer variable ui.prefersReducedMotion in about:config and set to value 1.
I think the resulting observation of much lower CPU load confirms that the underlying cause is some tab animations (throbbers) that keep churning. If this animation business was made ON by default in v104.0 (I do not know), then we have a model of why the problem suddenly appeared in 104.0 and is still present in 110.0.1. There is still a bug somewhere, but the above is a workaround.
Search: firefox disable throbbers
Reference: https://www.reddit.com/r/FirefoxCSS/comments/spgzdw/how_to_hide_tab_throbber_and_loading_burst_in/
Vent mode: How many hours of user time and developer time are these UX people going to waste by inserting new defaults for vanity/beautification code that is NOT ROBUST!? At the absolute minimum, any such change should be prominently mentioned in the RELEASE NOTES. Come to think of it, each release note should have a section about any changes in default settings, and names of the settin. These kinds of problems happen with alarming frequency, and waste a lot of time.
|
|
Reporter | |
Comment 20•2 years ago
|
||
I can also confirm that the topic bug does not exist in version 109.0.1, as have now recovered from backup a 103.2 profile that was not contaminated by 110.0.1 running, and it works fine with 109.0.1, no massive CPU usage.
|
|
Reporter | |
Comment 21•2 years ago
|
||
(In reply to reikred from comment #20)
I can also confirm that the topic bug does not exist in version 109.0.1, as have now recovered from backup a 103.2 profile that was not contaminated by 110.0.1 running, and it works fine with 109.0.1, no massive CPU usage.
Strike the above. It os wrong. The special setting about:config ui.prefersReducedMotion=1 is still needed to prevent excessive CPU usage. Sorry. UI was worjingon another bug that is absent in 109.0.1 and confused myself.
|
|
||
Comment 22•2 years ago
|
||
This may have been bug 1828587, which is now fixed.
Description
•