Confirmed users
512
edits
User:Jdm/SlowCSSSelectors: Difference between revisions
no edit summary
No edit summary |
No edit summary |
||
| Line 49: | Line 49: | ||
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. | 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. | ||
#2 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. | 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. | ||
#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. | 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. | ||