Open Bug 1247751 Opened 4 years ago Updated 3 months ago

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

Categories

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

defect

Tracking

(Not tracked)

People

(Reporter: tromey, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [btpp-fix-later])

Attachments

(1 file)

Attached file 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.
Now that I look again I think this test case came from some other bug.
I'm having trouble finding it though.
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).
Filter on CLIMBING SHOES
Priority: -- → P2
Whiteboard: [btpp-fix-later]
Summary: rule view hang → rule view hangs for a long time when there are many matching rules
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.