Boris Zbarsky
2010-01-19 05:36:21 UTC
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 getof these is likely to be for table rows and such, where the "normal
style computation" case would be hit.
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