Open Bug 1513285 Opened 4 years ago Updated 3 years ago
Use startup cache for fragments used with Moz
XULElement .parse XULTo Fragment
No description provided.
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
Assignee: nobody → enndeakin
Also, getSharedFragment should probably go somewhere else, like on Document, so you don't have to pass one.
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).
(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.
You need to log in before you can comment on or make changes to this bug.