Closed Bug 1405744 Opened 5 years ago Closed 5 years ago
stylo: High CPU use on www
.bbc .co .uk/news with Servo enabled on Mac
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13) AppleWebKit/604.1.38 (KHTML, like Gecko) Version/11.0 Safari/604.1.38 Steps to reproduce: Ensure Servo / Stylo / Quantum CSS is enabled by setting layout.css.servo.enabled to TRUE Navigate to www.bbc.co.uk/news macOS 10.13, MacBook Pro 2012 Actual results: CPU use is very high if Servo/Stylo is enabled and this page is frontmost. I get 50% CPU load if BBC News is frontmost tab (using Activity Monitor) with servo/Stylo enabled. Mac gets hot & battery is hammered. If I disable servo/Stylo (layout.css.servo.enabled to FALSE) & reload the page it drops to about 14% CPU load. This seems to be the case on both today's Nightly and Beta 57.0b5 Other sites I have tried don't seem to show this problem. Expected results: Similar CPU load with or without Servo / Stylo / Quantum CSS enabled. cheers now & thanks for Firefox
Component: Untriaged → CSS Parsing and Computation
Product: Firefox → Core
Summary: High CPU use on www.bbc.co.uk/news with Servo enabled on Mac → Stylo: High CPU use on www.bbc.co.uk/news with Servo enabled on Mac
Thanks for reporting this issue, Mark! Does the high CPU usage eventually stop or is it high as long as the BBC website is open in the foreground tab?
OS: Unspecified → Mac OS X
Priority: -- → P3
Summary: Stylo: High CPU use on www.bbc.co.uk/news with Servo enabled on Mac → stylo: High CPU use on www.bbc.co.uk/news with Servo enabled on Mac
Stays high, indefinitely as far as I can tell, minutes or hours The website is not challenging in terms of content, Safari uses circa 1% CPU for the same site
I can reproduce this. It seems that style recalculation is continuously triggered, and since Stylo would use multi-thread to do that, if the frequency is high enough, stylo would have a higher CPU usage. It is unclear to me, though, why we are recalculating style in that frequency.
But it seems to me that majority of time are spent on paint. Are we generating something that causes unnecessary repaint? The paint flashing doesn't show anything either...
I see an animation running on the site, if the animation is on out-of-view element, the cause of high CPU usage is bug 1303235, we don't implement the optimization yet on stylo.
(In reply to Hiroyuki Ikezoe (:hiro) from comment #5) > I see an animation running on the site, if the animation is on out-of-view > element, the cause of high CPU usage is bug 1303235, we don't implement the > optimization yet on stylo. And the animation is opacity that are not running on the compositor, I don't know why it's not running on the compositor yet.
I did confirm that the reason why the opacity animation is not running on the compositor is that corresponding layer is not generated because of out-of-view. That means bug 1303235 is the culprit.
Depends on: 1303235
I can reproduce the high CPU usage on Mac with or without Stylo enabled. I can't reproduce on Windows 10.
The opacity animation what I saw does not exist always. I don't know what the trigger for the animation is. Anyway, the high CPU usage will not appear if the opacity animation does not exist there.
Adding https://webcompat.com/issues/12417 I'm on macos 10.13 (17A405) using Firefox Nightly 58.0a1 (2017-10-15) (64-bit) <nav class="hot-topics menu-subnav" id="menu-subnav"> <span class="subnav-title">Hot Topics</span> <ul class="rotate-items"> <li style="animation: 15s ease-in-out 0s infinite normal none running rotate-items;"><a href="http://www.foxnews.com/politics/2017/10/15/trump-mcconnell-set-for-tense-talks-at-monday-meeting.html" data-omtr-intcmp="subnav1""">Trump, McConnell brace for meeting</a></li> <li style="animation: 15s ease-in-out 5s infinite normal none running rotate-items;"><a href="http://www.foxnews.com/entertainment/2017/10/15/james-corden-apologizes-for-jokes-about-harvey-weinstein-after-backlash.html" data-omtr-intcmp="subnav2""">Corden's joke bashed</a></li> <li style="animation: 15s ease-in-out 10s infinite normal none running rotate-items;"><a href="http://www.foxnews.com/politics/2017/10/15/chelsea-clinton-avoids-questions-about-harvey-weinsteins-donations-to-clinton-foundation.html" data-omtr-intcmp="subnav3""">Chelsea mum on Weinstein $$</a></li> </ul> </nav> For certain viewport size the animations come from the CSS, sometimes comes from the style attributes.
See Also: → https://webcompat.com/issues/12417
In the case of comment 10, it's bug 1237454. As per Chris' comment 8, this bug's case might be also bug 1237454, but I am not sure, I no longer see any opacity animations on bbc.com/news.
See Also: → 1237454
A suspicious bug (bug 1303235) has landed (actually it's not yet in nightly), does the high CPU usage still persist on builds with that fix? If it still persists, could you please check whether there are animations or not? You can check them on devtools animation inspector.
The latest nightly (20171019222141) which includes bug 1303235 has come.
I think you have cracked it, excellent work These are the CPU loads I see on BBC News homepage freshly loaded at 16:00 BST on MacOS 10.13:- Nightly 58.0a1 2017-10-20 Web Content ~4% Nightly ~7% Firefox 57.0b9 Web Content ~30% Firefox ~7% both with layout.css.servo.enabled TRUE I just downloaded (16:00 BST) another Nightly also called 2017-10-20 and that seems fine as well. So 58.0a1 2017-10-20 seems to fix the high CPU load problem on the web content. (I think the the animation which caused the high load may only appear in the evenings BST. Perhaps it's related to sports results or something??) Thanks guys, now I've just spotted another bug on another page ... time to file that ... sorry :( Mark
Thank you Mark for the confirmation! (In reply to Mark from comment #14) > (I think the the animation which caused the high load may only appear in the > evenings BST. Perhaps it's related to sports results or something??) I should have worked for a whole day. :)
Awesome! Thanks for reporting this bug, Mark! I will resolve this bug as fixed in Beta 57 and Nightly 58 by bug 1303235.
The fix (bug 1303235) has not yet landed beta branch, just in case.
Attachment #8922006 - Attachment is obsolete: true
Attachment #8922007 - Attachment is obsolete: true
Bug 1303235 has been uplifted to Beta now. The fix should be verifiable in 57b12 shipping on Friday.
You need to log in before you can comment on or make changes to this bug.