One thing that comes to mind is how some code registers app specific observers so the code runs after the UI is displayed. https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/nsUpdateService.js#180 https://dxr.mozilla.org/mozilla-central/source/devtools/shared/system.js#24 https://dxr.mozilla.org/mozilla-central/source/addon-sdk/source/lib/sdk/system/xul-app.jsm#48
Perhaps having a single category for after UI has been displayed that components can specify in their manifests so they are initialized at that time similar to how profile-after-change is typically used. This way they wouldn't have to initialize just to register an observer so the work happens after theUI is displayed. https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/nsUpdateService.manifest#12 Robert On Tue, Aug 8, 2017 at 5:42 PM, Kris Maglione <kmagli...@mozilla.com> wrote: > One of my biggest frustrations in profiling startup performance has been > the fact that exactly which code runs during before or after first paint > changes based on arbitrary timing factors. If I make a 5ms improvement to > one section of code, a 100ms chunk of code winds up running after first > paint rather than before. If I make a 5ms improvement to another section of > code, a 150ms chunk of code winds up running *before* first paint rather > than after. This also shows up in the ts_paint timings on talos, where we > have a fairly consistent cluster of high times, a fairly consistent cluster > of low times, and very little in-between. > > Presumably, if we're OK with these chunks *ever* running after first > paint, then they should always run after first paint. And vice versa. > > I've made various attempts to get a handle on this, but never with much > success. The last time, I got as far as fixing the broken TaskTracer build > before I finally gave up trying to find a useful way to analyze the data. > What I'd really like is a handle on what tasks are run, when, who schedule > them (and when), and what code they run. > > After that, I'd ideally like to find a way to run async tasks during > startup so that I'm guaranteed which parts run before first paint and which > run after. > > Has anyone else made any progress on this front? Are there any other tools > that I'm overlooking? Is there a sensible path forward? > > Thanks. > _______________________________________________ > firefox-dev mailing list > firefox-...@mozilla.org > https://mail.mozilla.org/listinfo/firefox-dev > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
