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)

enhancement

Tracking

()

RESOLVED FIXED
Firefox 67
Tracking Status
firefox66 --- wontfix
firefox67 --- fixed

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.
Whiteboard: [fxperf]
Blocks: 1515795
No longer blocks: 1515795
See Also: → 1515795
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
I this profile https://perfht.ml/2GTMeO1 this bug represents a third of the time it took to open a new browser window.
(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.
Priority: -- → P3
Depends on: 1515799
Whiteboard: [fxperf] → [fxperf:p2]
Component: General → Graphics: WebRender
Product: Firefox → Core

Bot fail? This was on the right component.

Component: Graphics: WebRender → General
Flags: needinfo?(sledru)
Product: Core → Firefox

(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)

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.

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)

Yes, I don't see anything in the stats anymore.

Assignee: nobody → vporof
Status: NEW → RESOLVED
Closed: 5 years ago
Depends on: deforestation
Flags: needinfo?(gijskruitbosch+bugs)
Resolution: --- → FIXED
Target Milestone: --- → Firefox 67
You need to log in before you can comment on or make changes to this bug.