<div dir="ltr"><div>One thing that comes to mind is how some code registers app specific observers so the code runs after the UI is displayed.</div><div><a href="https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/nsUpdateService.js#180">https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/nsUpdateService.js#180</a></div><div><a href="https://dxr.mozilla.org/mozilla-central/source/devtools/shared/system.js#24">https://dxr.mozilla.org/mozilla-central/source/devtools/shared/system.js#24</a></div><div><a href="https://dxr.mozilla.org/mozilla-central/source/addon-sdk/source/lib/sdk/system/xul-app.jsm#48">https://dxr.mozilla.org/mozilla-central/source/addon-sdk/source/lib/sdk/system/xul-app.jsm#48</a></div><div><br></div><div>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.<br></div><div><a href="https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/nsUpdateService.manifest#12">https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/nsUpdateService.manifest#12</a></div><br><div>Robert<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 8, 2017 at 5:42 PM, Kris Maglione <span dir="ltr"><<a href="mailto:kmaglione@mozilla.com" target="_blank">kmaglione@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
Presumably, if we're OK with these chunks *ever* running after first paint, then they should always run after first paint. And vice versa.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Has anyone else made any progress on this front? Are there any other tools that I'm overlooking? Is there a sensible path forward?<br>
<br>
Thanks.<br>
______________________________<wbr>_________________<br>
firefox-dev mailing list<br>
<a href="mailto:firefox-dev@mozilla.org" target="_blank">firefox-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/listi<wbr>nfo/firefox-dev</a><br>
</blockquote></div><br></div>