Closed Bug 1510321 Opened Last year Closed Last year
Stop creating a list of nodes in the DOM for builtin areas in Customizable
47 bytes, text/x-phabricator-request
|Details | Review|
After bug 1505734 this was pushed into the CUI code. However, it's quite expensive, and with the demise of XPCOM add-ons the list should be fully predictable, meaning we shouldn't need to check the DOM, which would make this code cheaper. Profiles indicate this loses us a few ms on startup. :bgrins has a profile.
Here's the referenced profile: https://perfht.ml/2EDHOcX. I had consistently seen this as ~15ms on a local build pre Bug 1505734. I just did a new run and am seeing only 3-4ms on registerToolbarNode. This could be either the move away from XBL somehow made this faster, or just inconsistency in measurements (different hardware, OS version, etc). `./mach talos-test -a tpaint --gecko-profile` (new window time only) - 3ms - https://perfht.ml/2DNicIG `./mach talos-test -a ts_paint --gecko-profile --cycles 2` - 4ms - https://perfht.ml/2DMxVYw I'll do a talos-other try push with --talos-profile and see what those look like.
Push with a bunch of profiles: https://treeherder.mozilla.org/#/jobs?repo=try&revision=001e2382fd8c55aeb5d68e4c7f1b35210a6682b5&selectedJob=214169015. If I click on "open in perf-html.io" on something like ts_paint and filter on "registertoolbarnode" I see generally 2-4ms there as well. This is less than I remember, but after re-looking at the referenced profile in Comment 1, registerToolbarNode was only a part of the toolbar_XBL_contructor time (~4ms out of ~12). The rest of the time seemed to be firing other XBL constructors (more toolbars and tabbrowser-tabs). Even still, this is all happening before first paint so even dropping a few ms would be a win.
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/da642018d1c6 avoid calling buildArea for all the builtin toolbars, r=jaws,bgrins
You need to log in before you can comment on or make changes to this bug.