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? > This reminded me of an old thread from 2013: https://groups.google.com/d/msg/mozilla.dev.platform/oKRBRqQbalk/D_YYWex83X4J 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 spinning). 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. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
