Re: Selector matching and caching (aka kill RuleProcessorData)

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