I've been thinking about more things that we can share in the style system (i.e., objects that we currently have separate instances of for separate documents, but that could be shared between documents). The idea would be both to improve performance of XUL (identical documents and not-identical documents) and to improve performance of Web pages on the same site.
In particular, I think we could do the following things: (1) Have style sheets in an nsExpirationTracker-based cache. (I want them to expire a few seconds after leaving a page that uses them, in case the leaving a page is in order to go to another page that uses the same style sheets, which is reasonably common.) This probably needs to (a) be a cache of (origin * style sheet), not just style sheet, and (b) revalidate the style sheet with the Necko cache and only re-use it if the Necko cache says it's still the same. I'm not sure how easy it would be to do (b). (2) Make an object that we have one of for each set of the things that can influence the data in the rule tree. This is so we can share computed style data between arbitrary documents, as long as they have they match on a small number of dimensions that affect the computed data (is-chrome, quirks-mode, text-zoom, full-zoom, and a few other things). (I think this no longer needs all the stuff I imagined in https://bugzilla.mozilla.org/show_bug.cgi?id=117568 because the new thebes font backends don't appear to give you different font metrics object depending on the device context. Though we probably still ought to formalize that by getting the fonts off a singleton... which would also let us share the font cache more.) Anything that currently calls RebuildAllStyleData needs to influence which of these objects we choose. (3) Share the rule tree between documents, and attach the root of the rule tree (and half the stuff in nsStyleSet, which would need to be split into two classes) to the object created in step (2). (4) Share style contexts between documents by making the half of nsStyleSet that we created in step (3) do the equivalent of FindChildWithRules for the root style context. (And potentially make FindChildWithRules itself more accurate by using a hash table when the child count gets high, just like we do for rule nodes.) (5) Actually cache style contexts on XUL prototype documents so that we don't have to rerun selector matching when opening new windows. This depends on (3). Step (1) will reduce memory footprint and time spent parsing CSS when using multiple pages on the same site or multiple XUL documents using the same style sheets (or do we already have some optimizations here that I'm forgetting?). It will also mean we'll have identical CSS rules for sharing in steps (3) and (4). Steps (3) and (4) (which really aren't useful without (1), except for the case where we're already sharing style sheets on XUL prototype documents) would both reduce memory footprint of style data and mean that we spend less time computing style data (everything inside nsRuleNode::WalkRuleTree) since we'll already have it cached. Step (5) could mean that we could skip doing selector matching when opening new XUL windows. If this worked, it would probably be the most significant performance win here. However, at least for the Firefox browser window, I think we're probably making too many dynamic changes to nodes for this to be useful, since it would only really be useful in cases where we make no dynamic changes (e.g., attribute changes, insertion of XBL bindings) to a node or any of its ancestors. (I'd also note that it a callgrind profile of Firefox new browser window performance, we spend 9.94% of the time in nsCSSFrameConstructor::ProcessPendingRestyles, which seems like we're doing a lot of dynamic changes that would hurt this optimization. That said, we're spending 13.57% of the time between nsStyleSet::ResolveStyleFor, ResolvePseudoStyleFor, and ProbePseudoStyleFor.) Any thoughts on these ideas and whether they'd be practical or useful? -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
