Closed
Bug 1515794
Opened 6 years ago
Closed 5 years ago
Avoid constructing custom element and/or XBL binding code for <tree>s in browser.xul on DOMContentLoaded to avoid the associated overhead
Categories
(Firefox :: General, enhancement, P3)
Firefox
General
Tracking
()
RESOLVED
FIXED
Firefox 67
People
(Reporter: Gijs, Assigned: vporof)
References
(Depends on 1 open bug)
Details
(Whiteboard: [fxperf:p2])
Right now, profiles show that the connecting of the tree UA widget causes us to call _ensureColumnOrder in tree.xml, which requires constructing a boxobject for the tree, which trips webrender, which blocks the main process for a significant proportion of time (easily 120-250ms on my machine). This was previously tracked in bug 1508213. It's unclear if this has regressed or if there's just more optimization to be done, but we'll still pay a similar-ish cost for initializing webrender at a different point.
Either way, we should be able to avoid this by constructing trees at runtime instead of having them hardcoded in the markup.
Reporter | ||
Updated•6 years ago
|
Whiteboard: [fxperf]
Reporter | ||
Updated•6 years ago
|
Reporter | ||
Updated•6 years ago
|
Summary: Avoid constructing UA widgets and/or XBL binding code for <tree>s in browser.xul on DOMContentLoaded to avoid the associated overhead → Avoid constructing custom element and/or XBL binding code for <tree>s in browser.xul on DOMContentLoaded to avoid the associated overhead
Comment 1•6 years ago
|
||
I this profile https://perfht.ml/2GTMeO1 this bug represents a third of the time it took to open a new browser window.
Reporter | ||
Comment 2•6 years ago
|
||
(In reply to Florian Quèze [:florian] from comment #1)
> I this profile https://perfht.ml/2GTMeO1 this bug represents a third of the
> time it took to open a new browser window.
Seems that most of that is just that we're forcing the creation of a compositor and it uses sync IPC, which in this instance took a "long" time... but I expect we'd have to pay that cost somewhere else if we fixed this bug.
Updated•6 years ago
|
Priority: -- → P3
Updated•6 years ago
|
Whiteboard: [fxperf] → [fxperf:p2]
Updated•6 years ago
|
Component: General → Graphics: WebRender
Product: Firefox → Core
Comment 3•6 years ago
|
||
Bot fail? This was on the right component.
Component: Graphics: WebRender → General
Flags: needinfo?(sledru)
Product: Core → Firefox
Comment 4•6 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #3)
Bot fail? This was on the right component.
Yes, we are trying to assign 'General' to more specific components when possible (it is often possible). This was a bad result.
Flags: needinfo?(sledru)
Comment 5•6 years ago
|
||
I am not convinced that Firefox::General can be the right component :)
Anyway, as a human, reading comment #0, I could have made the same call.
Comment 6•5 years ago
|
||
I think this was fixed as of Bug 1523957 / https://hg.mozilla.org/mozilla-central/rev/a6606e852767#l4.18. Can you confirm this can be closed?
Flags: needinfo?(gijskruitbosch+bugs)
Reporter | ||
Comment 7•5 years ago
|
||
Yes, I don't see anything in the stats anymore.
Assignee: nobody → vporof
Status: NEW → RESOLVED
Closed: 5 years ago
status-firefox67:
--- → fixed
Depends on: deforestation
Flags: needinfo?(gijskruitbosch+bugs)
Resolution: --- → FIXED
Target Milestone: --- → Firefox 67
Updated•5 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•