Having lots of messages in the browser console causes very slow restyles
Categories
(DevTools :: Console, defect, P2)
Tracking
(Not tracked)
People
(Reporter: florian, Unassigned)
Details
See this profile where we are continuously triggering restyles of 62000+ elements: https://perfht.ml/2ZjnCT8
I might have had javascript.options.mem.log set to true for some of the browsing session, which sent a lot of output to the console.
This is a profile of what happened when I closed the console after I realized the console was what was causing my Firefox parent process to use so much CPU: https://perfht.ml/2F3wMf7
There's about 750ms of JS (on a fast machine) destroying stuff.
Reporter | ||
Comment 1•6 years ago
|
||
(In reply to Florian Quèze [:florian] from comment #0)
See this profile where we are continuously triggering restyles of 62000+ elements: https://perfht.ml/2ZjnCT8
Emilio, any advice about how we could figure out which elements and which CSS rules are involved in this?
Would it be possible to include information in profiles to make this information easily discoverable? (maybe pseudo stack frames when parallel styling is disabled?)
Comment 2•6 years ago
|
||
Can you get a profile with sequential styling (there's a checkbox in the profiler UI)? That'd show if we're spending a lot of time invalidating style or recomputing styles.
The first thing that caused the restyle is some DOM removal, which probably means that there's some :{nth,first,last}-{child,of-type}
selectors or a sibling combinator (~
or +
).
I bet we're hitting this code path: https://searchfox.org/mozilla-central/rev/c606cdd6d014fee4034da1702d484c0d41b604c9/layout/base/RestyleManager.cpp#420
And devtools is removing messages from the beginning, and one by one or something, so it's probably restyling all siblings over and over. Bug 1406622 and co should make this better, if that's right.
Updated•6 years ago
|
Updated•2 years ago
|
Description
•