Open
Bug 1513285
Opened 4 years ago
Updated 5 months ago
Use startup cache for fragments used with MozXULElement.parseXULToFragment
Categories
(Toolkit :: XUL Widgets, task, P3)
Toolkit
XUL Widgets
Tracking
()
NEW
People
(Reporter: enndeakin, Unassigned)
References
Details
Attachments
(1 file)
17.00 KB,
patch
|
Details | Diff | Splinter Review |
No description provided.
Reporter | ||
Comment 1•4 years ago
|
||
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
Reporter | ||
Comment 2•4 years ago
|
||
Also, getSharedFragment should probably go somewhere else, like on Document, so you don't have to pass one.
Comment 3•4 years ago
|
||
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•4 years ago
|
||
(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.
Updated•4 years ago
|
Type: enhancement → task
Updated•4 years ago
|
No longer depends on: war-on-xbl
Reporter | ||
Updated•4 years ago
|
Assignee: enndeakin → nobody
Comment 5•4 years ago
|
||
Not sure if we'll do this, but if we do it would be part of unification for parseXULToFragment in Bug 1590573
Blocks: 1590573
Updated•5 months ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•