On Wednesday 2010-01-06 17:04 -0500, Boris Zbarsky wrote: > I tried hacking up SelectorMatches/SelectorMatchesTree to just match > directly on the node instead of on RuleProcessorData and changed > various callsites to not actually allocate RuleProcessorData > structs, more or less. This sped up the SlickSpeed querySelector > test by a good bit (40% or so), as expected, since in that case we > only match each data against one selector so the caching is not > worth it. I also tried the patch on a complete reframe of the HTML5 > single-page spec, and it looks like it's a slight win there too > (order of 50ms out of 1200ms). This test is more interesting, since > this is the situation the RuleProcessorData is supposed to help > with... however it might be that namespace+tag+id+classes are fast > enough to get and eliminate enough selectors that in practice the > more complicated caching isn't worth it, at least on this page.
Sounds good to me. When RuleProcessorData was created (and it was a big performance win at the time), there was much more XPCOM involved in getting the various pieces of information involved. > That leaves mNthIndices. As a first cut we could just not cache Maybe we could cache (somewhere?) the indices for the two elements that needed them most recently? That would let us do prev-sibling optimizations and node-matches-multiple-selectors optimizations. -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/ _______________________________________________ dev-tech-layout mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-layout
