Re: Figuring out and controlling what tasks run before first paint

2017-08-09 Thread Honza Bambas 
What you are looking for sounds pretty much like my Backtrack project 
[1].  It's still under development, tho, but I have strong motivations 
to move it forward in Q4/17. The goal of Backtrack is exactly what you 
are looking for - find the right scheduling prioritization.  It's said 
we don't have something like that ready right now, for 57.


I already proposed some latest details on Backtrack to Marcus Stange and 
Nicholas Nethercote to replace TaskTracer with it, will cc you on the 
thread.


-hb-


[1] https://www.janbambas.cz/backtrack-meets-gecko-profiler/

On 8/9/17 2:42 AM, Kris Maglione 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.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Figuring out and controlling what tasks run before first paint

2017-08-08 Thread Gregory Szorc 
On Tue, Aug 8, 2017 at 5:42 PM, Kris Maglione  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

Re: Figuring out and controlling what tasks run before first paint

2017-08-08 Thread Kris Maglione 

On Tue, Aug 08, 2017 at 06:09:05PM -0700, Robert Strong wrote:

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.


The running after first paint part is probably fairly easy. For 
most of the cases I'm thinking of, a promise that resolves at 
the right time, in the middle of a promise chain, should be 
enough.


It's the figuring out what's causing things to run, and ensuring 
that things get run before first paint that's more of a problem. 
We do a lot of async things at startup, like file reads and 
off-thread parses. A lot of those things wind up split up into 
multiple operations, and the event loop is so saturated during 
startup if they miss a chance to run, they often wind up running 
after first paint. If we do something like spin the event loop 
to make sure they run in time, extra things run before paint.


So perhaps it would be a fairly simple problem if we ensured 
that everything that runs during startup explicitly defers 
things that don't need to run before paint. But at this point, 
it's so hard to get a hold on what's being scheduled and why 
that I don't even know where to start.



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

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Figuring out and controlling what tasks run before first paint

2017-08-08 Thread Robert Strong 
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  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-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Figuring out and controlling what tasks run before first paint

2017-08-08 Thread Kris Maglione 
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.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform