Figuring out and controlling what tasks run before first paint

Robert Strong rstrong at mozilla.com
Wed Aug 9 01:09:05 UTC 2017


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 <kmaglione at 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-dev at mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20170808/9bb4fbe0/attachment-0001.html>


More information about the firefox-dev mailing list