On 1/6/10 6:03 PM, L. David Baron wrote:
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.
Sure. I'm not saying we didn't need it before!
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.
Most simply, the document could have a two-element cache. Each element
would have a pointer to an nsIContent and its indices. When an
nsIContent is destroyed or changes ownerDocument, it would check the
cache and if one of the cached pointers is to itself it would clear the
cache.
We'd probably also need to clear the cache any time there's a DOM
mutation or something.
Seem ok?
-Boris
_______________________________________________
dev-tech-layout mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-layout
