From MozillaWiki
Jump to: navigation, search

Functions like SelectorMatches show up in C++ profiles when CSS selector matching is being a problem. However, that is too low level - individual calls of SelectorMatches are fast, but the sheer volume of calls causes the problem. Instead, RuleHash is used to avoid even looking at most selectors.

11:56 <bz> so in Gecko there are at least 3 ways in which a selector can be expensive

11:57 <bz> 1) The selector might need to be matched against a bunch of nodes and be slow to match

11:57 <bz> This is what you can detect from EnumerateAllRules

11:58 <bz> basically, measure the time needed for the ContentEnumFunc call, and accumulate it in the selector

11:58 <bz> this won't add any new code to SelectorMatches, which is good

11:58 <bz> and if you do it only when profiling is active somehow, it shouldn't be a perf hit in general

11:59 <bz> 2) The selector might be very broad and catch a lot of dynamic changes, triggering a lot of style recomputation on dynamic changes

11:59 <bz> 3) The selector might be very broad and catch a lot of sibling stuff, triggering a lot of style recomputation on DOM insertion/removal

12:00 <bz> not sure how best to account for 2 and 3

12:03 <bz> #2 is mostly nsCSSRuleProcessor::HasAttributeDependentStyle and nsCSSRuleProcessor::HasStateDependentStyle

12:04 <bz> #3 is the various places where the rule processor sets the slow selector flags on the node and the places in presshell and frame constructor that then examine those flags....


12:05 <bz> The problem is not the call

12:05 <bz> the problem is that if it matches, we restyle either the node or the node and all its descendants or the node and all its following siblings and all descendants of all those

12:05 <bz> depending on the exact selectors that matches

For #1, we can add a timer accumulator to the nsCSSSelector class, and surround all calls to SelectorMatches with a timer that adds its duration to this accumulator. To expose this information, we could potentitally add a method to iniDOMUtils.idl that takes a DOM CSS rule and returns profiling data for all selectors within it? This requires further discussion.

With regards to #2, it would be best served by timing restyles that occur and linking them to triggering CSS selectors, but this is complicated by restyle coalescing in the engine. This can be skipped for this project.

Likewise, #3 would be best served in a similar manner as #2, but we can at least expose a flag on nsCSSSelector to indicate that the selector was involved in a LATER_SIBILINGS restyle. Those are some of the worst offenders, so this knowledge can be useful. This could be part of the information exposed in #1.