Confirmed users
512
edits
User:Jdm/SlowCSSSelectors: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
No edit summary |
||
| Line 15: | Line 15: | ||
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. | 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 | |||