1247751 - rule view hangs for a long time when there are many matching rules

Status: RESOLVED FIXED

(DevTools :: Inspector: Rules, defect, P2)

Description

[Tom Tromey :tromey]

Attachment: css-tp.html

I'm using a recent fx-team.

Open the attached file.
Then open the rule view.
Now click on the <a> element.

For me this results in a hang.
In e10s the rule view is just empty but apparently the content process
has hung; so I would suspect a bug in one of the actors.

Comment 1

[Tom Tromey :tromey]

Now that I look again I think this test case came from some other bug.
I'm having trouble finding it though.

Comment 2

[Patrick Brosset <:pbro>]

Oh wow, I can reproduce too. 
I tested with a much lower number of a{} rules in the test file (~500) and the rule-view takes about 3 seconds to appear.
I also tested with ~2000 a{} rules, and the rule-view took ~40 seconds to load!
So I don't think there's any error, it just takes a whole lot of time to load.

With e10s, it's fairly easy to see what's going on:

For about 35 seconds, the rule-view is empty, and that's while the server request is being processed. You can see, for instance, that the toolbox remains responsive (you can still switch tabs), and buttons background colors change on hover, etc... 
However the content process is blocked as you said. For instance the highlighter (which lives in content) remains on screen for these 35 seconds, and doesn't get refreshed when you resize the window.
So the content process is basically busy trying to retrieve these 2000 rules.

Then, for about 5 seconds, the main process hangs. I think that's when the response has finally been generated and has reached the toolbox. It then takes all that time to just generate the DOM necessary to display those 2000 rules. During that time, the toolbox freezes and is unresponsive.

So, we need to determine what exactly takes the most time on the server to process 2000 rules.
And, perhaps, we should cap how many rules we want to work with anyway. It's very unlikely that anyone would have defined 2000 rules for a single element, and would want to see them all in the rule-view.

The perf tools in non-e10s mode (so that I could also profile the server) show that the canSetRuleText getter in styles.js takes the most time (in fact, allRulesHaveSource does), and adding an early 'return true;' at the top of this getter basically fixes the issue for me (it still takes a long time to render the UI, but the 35s of server-side time are gone).

Comment 3

[Patrick Brosset <:pbro>]

Filter on CLIMBING SHOES

Comment 4

[Nicolas Chevobbe [:nchevobbe]]

I'm still seeing this, here's a profile: https://share.firefox.dev/427Ujog

we're taking a long time inside _computeRuleindex: https://searchfox.org/mozilla-central/rev/734887cfb193b5697e59a857d394e8d4245996db/devtools/server/actors/style-rule.js#607-643

Comment 5

[Nicolas Chevobbe [:nchevobbe]]

Looks like most of the cost is because of Xray wrapper, we may benefit from moving this to C++ instead

Comment 6

[Nicolas Chevobbe [:nchevobbe]]

Attachment: Bug 1247751 - [devtools] Add InspectorUtils.getRuleIndex. r=emilio.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/21d52b57ab6a
[devtools] Add InspectorUtils.getRuleIndex. r=emilio,devtools-reviewers,ochameau.

Comment 8

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/21d52b57ab6a

Comment 9

[Nicolas Chevobbe [:nchevobbe]]

Before, on my machine, more than 7s was spent in _computeRuleIndex.
With the patch, for the same page, it's down to 50ms (99% improvement)
Profile: https://share.firefox.dev/3UMnf3M

Comment 10

[Nicolas Chevobbe [:nchevobbe]]

== Change summary for alert #41510 (as of Mon, 19 Feb 2024 22:12:24 GMT) ==

Improvements:

Ratio	Test	Platform	Options	Absolute values (old vs new)
4%	damp custom.inspector.manyrules.selectnode	windows10-64-shippable-qr	e10s fission stylo webrender	517.36 -> 494.16
4%	damp custom.inspector.manyrules.selectnode	windows10-64-shippable-qr	e10s fission stylo webrender-sw	517.17 -> 494.61
3%	damp custom.inspector.manyrules.selectnode	linux1804-64-shippable-qr	e10s fission stylo webrender	592.82 -> 572.92

For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=41510