Figuring out and controlling what tasks run before first paint

Gregory Szorc gps at
Wed Aug 9 01:45:44 UTC 2017

On Tue, Aug 8, 2017 at 5:42 PM, Kris Maglione <kmaglione at> 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?

This reminded me of an old thread from 2013:

I'm pretty sure that thread eventually led to
toolkit/components/asyncshutdown (which Yoric wrote). That's a really nifty
mechanism for managing component shutdown. IIRC it helped eliminate a
number of race conditions, edge cases, and bad practices (like event loop

AFAIK we never replicated that feature to startup or came up with a more
modern/generic mechanism to manage components and their complex
dependencies throughout their lifetime. (It is a hard problem after all.)
Re-reading that old thread and your issues here, it might be worth
re-visiting those grand ideas from 2013.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the firefox-dev mailing list