Support creating XHTML documents with the XUL prototype cache

RESOLVED FIXED in Firefox 67

Status

()

enhancement
P4
normal
RESOLVED FIXED
4 months ago
3 months ago

People

(Reporter: bdahl, Assigned: bdahl)

Tracking

(Blocks 1 bug)

unspecified
mozilla67
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox67 fixed)

Details

Attachments

(1 attachment)

Assignee

Description

4 months ago

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.

Depends on: 1527733

Updated

4 months ago
Priority: -- → P4
Assignee

Comment 1

4 months ago

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.

Assignee

Comment 2

4 months ago

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.

Assignee

Updated

3 months ago
No longer blocks: top-level-html
Assignee

Updated

3 months ago
Depends on: 1533881
Assignee

Updated

3 months ago
Blocks: 1533881
No longer depends on: 1533881

Comment 3

3 months ago
Pushed by bdahl@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/f996bb0f3d23
Share XUL prototype cache with XUL and XHTML. r=smaug

Comment 4

3 months ago
bugherder
Status: NEW → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla67
You need to log in before you can comment on or make changes to this bug.