Open Bug 1425916 Opened 7 years ago Updated 2 years ago

Very high CPU usage on MacOS (profile included)

Categories

(Core :: Web Painting, defect, P3)

Product:
Core
Component:
Web Painting
Platform:
x86_64
macOS
Type:
defect

Tracking

()

People

(Reporter: zbraniecki, Unassigned)

References

Details

(Keywords: power) 

I was able to reproduce some variant of bug 1420699 on my colleague's machine.

Firefox: Nightly from today
macOS: 10.12.6 (16G1036)
MacBook Pro (13-inch, 2016, Four Thunderbolt 3 Ports) CPU: 3,3 GHz Intel Core i7 Memory: 16 GB 2133 MHz LPDDR3 GPU: Intel Iris Graphics 550 1536 MB

The video of the CPU usage is here: https://www.youtube.com/watch?v=7mwk_scs1l4&feature=youtu.be

The profile (captured a couple days later with the same behavior) here: https://perf-html.io/public/91f5fc35e00743936fd6a50da6729a4d9d4dc268/calltree/?hiddenThreads=&thread=2&threadOrder=0-2-3-4-5-1&v=2

Things that contribute to the perception of the high CPU load:

1) When slack tab is in the background, the CPU usage is very low (as expected)
2) When slack tab is selected, CPU usage is abnormaly high (40%+) even without any user action
3) When user moves mouse over static page (hg.mozilla.org) the CPU spikes to 20%
4) When user moves mouse over slack, it spikes to 60-70%
5) When user starts scrolling slack it jumps to 100% instantly

I think it's worth analyzing the profile and seeing if we can get something actionable here.
CC'ing :flod (who's machine the profile/video were recorded on) in case anyone has more questions/requests for more profiling.
(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #0)
> 5) When user starts scrolling slack it jumps to 100% instantly

This step was added compared to the YouTube video. Happy to do more testing if it helps.

In the profile, screen was taking the left half of the screen.
(In reply to Francesco Lodolo [:flod] from comment #2)
> In the profile, screen was taking the left half of the screen.

*the browser's window* was taking the left half of the screen (I blame jetlag)
The CPU usage with slack or hg tabs are perhaps slightly puzzling but the scrolling CPU usage is interesting. Maybe kats or mstange have thoughts on it?
Flags: needinfo?(mstange)
Flags: needinfo?(bugmail)
One more important detail about the config: screen is set to "More space" (1680x1050px)
Seems like a lot of alloc/dealloc churn from many small restyle changes on the slack. A fair bit of reflow as well, though most of the time is waiting for memory operations to return.
Around ~25s the CPU usage is mostly due to display list building and frame layer building: https://perfht.ml/2BhJ9nG
Flags: needinfo?(mstange)
It looks like slack reimplements a bunch of stuff inside the webapp (e.g. the scrollbar) and so basically triggers a repaint every time we scroll. It's not surprising that it's spending so much time in display list building and frame layer building and repainting. If it were a more "static" page like hg.m.o it wouldn't use so many cycles. From the profile I don't really see anything that stands out as low-hanging fruit in terms of optimizations.
Flags: needinfo?(bugmail)
For what it's worth, I tried Safari and Chrome on the same pages:
* Safari has a similar behavior as Firefox (maybe slightly less CPU on scrolling Slack)
* Chrome is definitely doing better (CPU spikes to about 50%)
* For both, there seems to be 20-30% CPU usage showing a page with animated reactions
* Only Firefox has the weird behavior, where the CPU goes up to almost 20% just by moving the mouse pointer on a static page like hg.mozilla.org (in a white area, not even on links)
(In reply to Francesco Lodolo [:flod] from comment #9)
> * Only Firefox has the weird behavior, where the CPU goes up to almost 20%
> just by moving the mouse pointer on a static page like hg.mozilla.org (in a
> white area, not even on links)

I suspect this is because of the code at [1] which was added to support APZ keyboard scrolling. We can probably improve that somewhat by adding a dedicated PLayerTransaction message for that and not doing all the rest of work that's involved in an empty transaction.

[1] https://searchfox.org/mozilla-central/rev/f0ab0b072ae090f11d6b02b7cf1e0829b4f08882/layout/base/PresShell.cpp#6820-6825
Matt: see comment 10. Can we do the scroll focus update with something cheaper than a SchedulePaint()?
Flags: needinfo?(matt.woodrow)
Priority: -- → P3
Component: General → Layout: Web Painting
Kats' suggestion seems reasonable to me!

Are you going to work on this Kats? I assume we need it to work with both Layers and WR.
Flags: needinfo?(matt.woodrow)
Does anyone know why Slack is re-implementing scrolling manually? Is there something missing from the native scrolling, or are they working around bugs?
Yeah I can work on the thing in comment 10, but I'll do it in a dependent bug since I don't know for sure if it will fix this bug or not. Filed bug 1426653 for it.
:flod - can you test the upcoming nightly with the patch from bug 1426653 in against the test scenario on your machine?

I believe our expectation is that scrolling will be cheaper, and potentially (?) mouse movement over the website. I'd still expect the animated icons on slack to be unreasonably expensive on CPU, but if some of the symptoms you reported are fixed, maybe we can double down on the others.
Flags: needinfo?(francesco.lodolo)
I've update macOS in the meantime, so I'm currently on 10.13.2 (17C205) and 59.0a1 (2018-01-11) (64 bit)

- Moving the cursor on static page still raises CPU around 15% for one content process (it seems a little lower than before).
- I still see one content process going in the 80-100% when scrolling Slack.

https://perf-html.io/from-addon/calltree/?hiddenThreads=&thread=2&threadOrder=0-2-3-4-5-1&v=2
Flags: needinfo?(francesco.lodolo)
(In reply to Francesco Lodolo [:flod] from comment #16)
> https://perf-html.io/from-addon/calltree/
> ?hiddenThreads=&thread=2&threadOrder=0-2-3-4-5-1&v=2

Forgot to share
https://perfht.ml/2AOY4Rf
(In reply to Francesco Lodolo [:flod] from comment #16)
> - Moving the cursor on static page still raises CPU around 15% for one
> content process (it seems a little lower than before).

The "it helped a small amount" seems similar to what was reported in bug 1427113.

> - I still see one content process going in the 80-100% when scrolling Slack.

As far as I'm concerned, this is expected behaviour because Slack is doing a lot of stuff on the main thread. I'm more worried about the CPU usage on a static/blank page.

Can you try with a build from the try push at [1] to see if it helps any? A profile from this build while moving the mouse on a blank/static page would be useful.

[1] https://treeherder.mozilla.org/#/jobs?repo=try&revision=453a17093a29668ec1f2885bbfafc71294062c22
See Also: → https://bugzilla.mozilla.org/show_bug.cgi?id=1427113
> As far as I'm concerned, this is expected behaviour because Slack is doing a lot of stuff on the main thread.

:flod - can you cross-check how the CPU load looks on Slack on Chrome or Safari? If they're similar then I think we have to drop this item.

If we can prove that other browsers handle the scenario substantially better, than maybe we should look into it more?
Flags: needinfo?(francesco.lodolo)
(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #19)
> If we can prove that other browsers handle the scenario substantially
> better, than maybe we should look into it more?

That's fair. But in that case let's split it out into a separate bug.
(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #19)
> > As far as I'm concerned, this is expected behaviour because Slack is doing a lot of stuff on the main thread.
> 
> :flod - can you cross-check how the CPU load looks on Slack on Chrome or
> Safari? If they're similar then I think we have to drop this item.

That should be covered in comment 9. They spike, less than Firefox (especially Chrome on Slack), but it's probably something we might need to live with.

Leaving the NI open to test comment 18.
(In reply to Francesco Lodolo [:flod] from comment #21)
> (In reply to Zibi Braniecki [:gandalf][:zibi] from comment #19)
> > > As far as I'm concerned, this is expected behaviour because Slack is doing a lot of stuff on the main thread.
> > 
> > :flod - can you cross-check how the CPU load looks on Slack on Chrome or
> > Safari? If they're similar then I think we have to drop this item.

I created a fresh profile in Firefox for this
https://youtu.be/gmNXKd7i3lI

* Firefox: moving the cursor around goes to 20%, scrolling is in the range 80-120% (one CP). What's bad is the amount of time it takes to go down.
* Safari: worse than Firefox on pointer moving (46%), slightly worse than Firefox in scrolling. I realized it was staying around 40% because the animated icon where showing, once hidden CPU got down faster than Firefox.
* Chrome: better than Firefox in scrolling, blazing fast to go down when I'm done scrolling.

If high CPU on scrolling can't be helped, it feels like the time needed to reduce CPU usage should.
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #18)
> https://treeherder.mozilla.org/#/
> jobs?repo=try&revision=453a17093a29668ec1f2885bbfafc71294062c22

opt build for Mac, clean profile
profile: https://perfht.ml/2D3bP50
video: https://youtu.be/VvXSr8rOfio
Flags: needinfo?(francesco.lodolo)
This profile shows that 99% of the time in all threads is spent idle. So either the thread(s) eating the CPU are not captured in the profile, or there's some other mismatch between what the profile is capturing vs what the activity monitor is capturing.
OS: Unspecified → Mac OS X
Hardware: Unspecified → x86_64
Is there any update on this bug? My partner's laptop - a MacBookPro12,1 - has the same issue with both Release and Beta. At launch - with no tab opens - thread(s) start eating the CPU and fans start to spin. I don't currently have access to the machine but this problem happens with Firefox only and with no active web content. As soon as I can get to the machine I will post a profile and a video.
As of bug 1444765 you can now get a profile of all the threads in a process. So if you're seeing this behaviour, the best thing to do is:

(1) install the gecko profiler add-on from https://perf-html.io
(2) wait until the CPU usage seems high
(3) open the "Activity Monitor" app, go to the CPU tab, sort processes by CPU usage, and note the PID of the Firefox process that's using the most CPU.
(4) in Firefox, click on the profiler icon in the toolbar, edit the threads filter to say "pid:<n>" (e.g. "pid:12345", without the quotes, where 12345 is replaced by the PID from the previous step), and hit start
(5) wait for a few seconds (10-15 seconds should be good) and then click on the profiler icon and the capture profile button. this will open a new tab with the gecko profile
(6) wait for the profile to finish symbolicating, and then click on the share button to upload it, and share the generated short url on this bug.

hopefully with the info from all the threads we should be able to find out which thread is eating the CPU.
I've created a profile as stated above. It can be found here: https://perfht.ml/2Cbeibv
Unfortunately it looks like the profile did not finish uploading :(

Can you try again?

Additionally, can you use Activity Monitor to grab a "sample" of the affected process?
New attempt: https://perfht.ml/2A9cVJ3

And another profile which hopefully helps solving this. My Mac still sounds like taking off when running Firefox

Profile here: https://perfht.ml/2ADYcpz

And here's a sample from Activitiy Monitor. Not from the same time period though https://pastebin.com/K1zZ6LJF

(In reply to jeroen from comment #31)

Profile here: https://perfht.ml/2ADYcpz

This one shows a lot of activity from the LastPass add-on in the parent process.

Going back to the original bug as filed, I think it was about CPU usage during mouse moving on Slack or on a blank page. From what I can tell, we were waiting for profiles of doing that. Unrelated "high CPU usage" profiles deserve their own bug, so as to not distract the conversation in this bug.

Keywords: power
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.