On 1/17/10 12:30 AM, Boris Zbarsky wrote:
I'll still do it and see how it goes. In practice, the most common use of these is likely to be for table rows and such, where the "normal style computation" case would be hit.
OK, I tried doing this (as in, implement the nth-index cache, and get rid of RuleProcessorData usage in selector matching altogether). One issue is that the way we currently compute the nth index means that the cache is basically never hit for anything but multiple :nth-* selectors for the same element; in particular going back to a previous sibling is actually somewhat expensive (involves an IndexOf), so we don't do it in GetNthIndex.... and hence can't benefit from having our previous sibling's index cached. That's about where we are right now for style matching, I think, but we do better on querySelector at the moment. I think we could change to use IndexOf, but I'm not sure it would be much of a win, if any. Perhaps worth revisiting once we have a linked-list DOM child storage.
The other issue I ran into is that IntrinsicState() can actually be somewhat expensive if called repeatedly without caching the result (e.g. the QI+addref+release that Link::LinkState does accounts for about 10% of the time on reframe of the HTML5 page with the patches in my tree).
Would people be ok with adding an mIntrinsicState to nsGenericElement, say, and caching the state? We know all the places the state might change anyway (they're the ones that currently call ContentStatesChanged), so those could be responsible for updating the cached state.
It might also be possible to remove the QI from LinkState by making bind/unbind on Link subclasses do more work to flag the in-document state on the Link. Would that be preferable to caching the state? It might be good enough to at least not regress performance on the HTML5 reframe test.
-Boris _______________________________________________ dev-tech-layout mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-layout
