From working on the browser.xul to browser.xhtml transition, we haven't been able to get the performance of XHTML to match XUL on talos tests (mainly ts_paint and tpaint). After some investigation the perf differences mainly seems to come from the prototype cache, namely:

• parsing the prototype cache from disk is faster
• the prototype cache can also stay in memory
• the way XUL document is constructed has much less overhead than XHTML (no buffering of nodes and flushing)
• load event ordering of XUL (load whole DOM then start layout)

I built some hacky prototypes to create XHTML documents from the cache and performance returns to near parity with XUL.

Luckily, most of the document creation from the prototype cache is fairly generic to any XML document, so it can be extracted out and also used for XHTML. My current strategy for extracting the prototype cache from XUL Document is:

• move the code that handles creating and loading a nsXULPrototypeDocument into a new nsIParser based class
• move all the prototype traversal code that creates DOM nodes (XULDocument::ResumeWalk and friends) into a new nsIContentSink based class

Then XULDocument and nsHTMLDocument can share the Parser/Content Sink to use the prototype cache.

Create a new parser (PrototypeDocumentParser) and content sink
(PrototypeDocumentContentSink) that can be used by both XUL and XHTML.

The new parser moves the code from XULDocument that handles creating and
loading a nsXULPrototypeDocument from either the cache or the source
file. Once the parser has finished loading the prototype it notifies the
content sink. The parser is largely a stub and would be better suited
for use as a nsBaseParser, but nsHTMLDocument unfortunately needs an
nsIParser.

The new content sink has the XULDocument code responsible for the
prototype traversal that creates the DOM (XULDocument::ResumeWalk and
friends) and fires off various events.

To unify XUL and XHTML, the XHTML readystate event sequence is used in
XUL. However, the layout path of XHTML loaded from the prototype cache
more closely follows XUL, where frame initializers and layout don't
start until the entire DOM is built.

One open question for cached XHTML, how do we want to mark/indicate that XHTML should cached in the prototype cache? We could cache all chrome priv XHTML, like XUL does. Though that seems like a decision we may want to revisit. Alternatively, we could have explicit levels of caching, e.g. some docs have no cache, some get a disk cache, some get memory.

https://hg.mozilla.org/mozilla-central/rev/f996bb0f3d23