1246087 - 25% CPU usage when many nodes are highlighted

Status: NEW

(DevTools :: Inspector, defect, P3)

Description

[arni2033]

>>>   My Info:   Win7_64, Nightly 46, 32bit, ID 20160204030229
STR:
1. Open attachment 8557479 [details]
2. Open Style Editor, create new style, paste the following code (without ">"s)
>   option:nth-child(4n){
>     cursor:auto;/**//**/
>   }
3.A) Hover mouse over selector "option:nth-child(4n)"
3.B) Open Inspector, select 4th <option> in markup, hover selector in ruleview tab in sidebar

AR: 25% CPU usage after Step 3
ER: Just like on Nightly 2014-11-06 and previous versions: (A) 5-10%   (B) 0-1%

Actually scenarios (A) and (B) had different result until 2014-11-07 (see above). That's really strange

Caused by: bug 985597 (presumably). Regression range (the best I got):
> https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2114ef80f6ae&tochange=b62ccf3228ba

Comment 1

[Patrick Brosset <:pbro>]

Attachment: profile.json

Locally I see ~15% of CPU usage.

Both cases (3A and 3B) use the SelectorHighlighter. This highlighter executes a querySelectorAll on a given selector, then limits the results to the first 100 matching nodes, and then instantiates a BoxModelHighlighter for each of them and shows them.

This, alone, shouldn't end up constantly using CPU, but the BoxModelHighlighter inherits from the AutoRefreshHighlighter. This is useful because if a node that's highlighted moves, then the highlighter will "follow" the node (particularly useful for animations).

Each instance of AutoRefreshHighlighter does the following:
- it runs a requestAnimationFrame loop
- calls node.getBoxQuads at each iteration
- compares the result with the previous result
- if the quads are different, it updates the highlighter.

In the test case, the quads are always the same, so the highlighter isn't updated. It's shown once and then never updated.

The way we get the quads is in devtools\shared\layout\utils.js in getAdjustedQuads.
Adding an early 'return [];' in this function drops the CPU to 10% instead of the 15% I was seeing.

Using the performance tool in the browser toolbox (on a non-e10s window, to capture everything), I can see a drop from 60fps to ~10fps when the highlighter is shown.

The flame chart shows that getAdjustedQuads is the one that takes the most time. About ~15ms, but with the test case, it's called 100 times.

I've attached my profile.

Comment 2

[Patrick Brosset <:pbro>]

Here's another use case:
- open https://www.mozilla.org/en-US/
- select the <li> element in the inspector that corresponds to the "Download Firefox" tile in the page. For me, it's #promo-download-fx-button > ul:nth-child(4) > li:nth-child(1)
- in the rule-view, click on the selector-highlighter button next to .download-button ul li
=> CPU usage goes from 2% to 5% for me, and that's just for one element that doesn't move.

- now mouse-over the "Download Firefox" tile to trigger the animation
=> CPU goes up to ~10% while the animation is playing and then back down to 5%

- click on the highlighter button again
=> CPU goes down to 2% again

Comment 3

[Patrick Brosset <:pbro>]

Filter on CLIMBING SHOES

Comment 4

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Platform triage meeting decision: This is an old regression, we will not be fixing this for Fx47.