Note: There are a few cases of duplicates in user autocompletion which are being worked on.

stylo: sequential style traversal is 3x slower than stock Gecko on myspace Talos testcase

RESOLVED FIXED

Status

()

Core
CSS Parsing and Computation
P1
normal
RESOLVED FIXED
6 months ago
3 months ago

People

(Reporter: bholley, Assigned: bholley)

Tracking

(Blocks: 3 bugs)

Firefox Tracking Flags

(Not tracked)

Details

We spend 57 ms doing a style traversal: https://clptr.io/2iFTo7q

Using the filter, we can see that we spend 38 ms matching selectors and 18 ms doing property cascading. 38 + 18 = 56, so there's no significant traversal overhead to speak of (at least in the sequential case), which is good.

I can rebuild all the style data for the same page on Gecko in 18 ms with [1].

Both selector matching and property cascading are costing us more than they should, which leads me to suspect that the style sharing cache may not be operating correctly. The next thing to do here is to compare how many elements we perform selector matching against in both Gecko and Stylo.

[1] From the web console:
var start = performance.now();
var s = document.createElement('style');
s.innerHTML = '*|* { color: red }';
document.head.appendChild(s);
s.remove();
window.getComputedStyle(document.body).color;
console.log(performance.now() - start);
Note that I ran this with STYLO_THREADS=1 to compare apples to apples. I'd like to achieve sequential parity (or something close), and _then_ optimize the parallelism.
Just wanted to point out this could also depend on _how many_ elements are we matching against, etc. So probably worth measuring that too.
(In reply to Emilio Cobos Álvarez [:emilio] from comment #2)
> Just wanted to point out this could also depend on _how many_ elements are
> we matching against, etc. So probably worth measuring that too.

This sounds like what I was talking about in comment 0, are you talking about something else? Did you mean selectors?
(In reply to Bobby Holley (:bholley) (busy with Stylo) from comment #3)
> (In reply to Emilio Cobos Álvarez [:emilio] from comment #2)
> > Just wanted to point out this could also depend on _how many_ elements are
> > we matching against, etc. So probably worth measuring that too.
> 
> This sounds like what I was talking about in comment 0, are you talking
> about something else? Did you mean selectors?

Sorry, I misread you and I thought that you were referring to performance of raw selector matching in comment 0, not number of traversed elements, nevermind.

In any case, both are something we should measure, preferably in isolation.
The stats in bug 1331856 indicate that we're getting zero hits on the style sharing cache, which likely explains a lot.
That's... Interesting, which are the reasons for the cache misses?

That being said, I doubt that accounts for the 3x slowdown (unless we spend a lot of time testing against it too).

Also, most of the time seems to be spent doing selector matching under get_matching_rules, so we should probably try to see what exactly is causing selector matching to be so slow.
Depends on: 1332525
Depends on: 1335941
Depends on: 1339703
Assignee: nobody → bobbyholley
Priority: -- → P1
Depends on: 1348935
Blocks: 1243581
Depends on: 1357304
Depends on: 1357973
Depends on: 1358375
Remeasured this - no-sharing sequential Stylo now spends ~17ms in Servo_TraverseSubtree, which is comparable or slightly better than the time that Gecko spends in ResolveStyleFor and WalkRuleTree.
Status: NEW → RESOLVED
Last Resolved: 3 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.