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.

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.