1513285 - Use startup cache for fragments used with MozXULElement.parseXULToFragment

Status: NEW

(Toolkit :: XUL Widgets, task, P3)

Comment 1

[Neil Deakin]

Attachment: Shared Fragments Loader

This demonstrates loading a fragment and caching the results. It doesn't yet actually use the startup cache, but it only loads and parses each fragment once per session, then just clones it for each use thereafter.

This patch changes two usages for findbar and treecol.
 
Some simple performance testing (by opening the browser and then the bookmarks library) shows:

Before:

0.5ms per call to parseXULToFragment

After:

1.1ms for the initial call to getSharedFragment
0.08ms for each call thereafter

Comment 2

[Neil Deakin]

Also, getSharedFragment should probably go somewhere else, like on Document, so you don't have to pass one.

Comment 3

[Brian Grinstead [:bgrins]]

cc'ing some folks who were discussing something similar regarding perf for Fluent and browser.xhtml startup at the last work week. We were discussing caching a live document into the startup cache (after Fluent but before any other JS had run). But if we instead added a way to cache a DocumentFragment that may be able to work for our use case as well.

First, put the bulk of browser.xul into a separate fragment instead of directly in the document. Then:

Cold startup:
- open browser.xul
- load and localize the fragment with Fluent
- store the fragment in startup cache
- import the fragment into browser.xul

Warm startup:
- open browser.xul
- load the localized fragment from the startup cache
- import the fragment into browser.xul

I could envision then making it more granular and splitting into individual fragments that could potentially be imported into the document at different times in the startup process (perhaps popupsets could wait until after first paint, or even the menu in certain platforms).

If that worked, then the transition to browser.xhtml or browser.html should have less of an impact, since the document itself would be a lot smaller (presumably the root node + styles + scripts).

Comment 4

[Brian Grinstead [:bgrins]]

(In reply to Neil Deakin from comment #1)
> Some simple performance testing (by opening the browser and then the
> bookmarks library) shows:
> 
> Before:
> 
> 0.5ms per call to parseXULToFragment
> 
> After:
> 
> 1.1ms for the initial call to getSharedFragment
> 0.08ms for each call thereafter

Do you have a theory as to why the initial call is slower - is this is due to moving the template out of JS and into a separate file?

FWIW I'd almost prefer to keep the template in JS for the current use Custom Element use cases (closer to the rest of the element, easier to script the conversion of, only loading the necessary DTDs), so assuming we could wire up a string-based template into the startup cache (maybe keying on a hash instead of the chrome URI) that could be better for the empty cache case.

Comment 5

[Brian Grinstead [:bgrins]]

Not sure if we'll do this, but if we do it would be part of unification for parseXULToFragment in Bug 1590573