One thing that comes to mind is how some code registers app specific
observers so the code runs after the UI is displayed.
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.
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?
> firefox-dev mailing list
dev-platform mailing list