1637024 - Implement an "after startup settled" event to defer expensive work

Status: NEW

(Toolkit :: Startup and Profile System, enhancement)

Description

[Alex Thayer [:alexical] (she/her)]

This is needed for several pieces of bug 1627071 (reducing and improving our general disk IO story during startup).

Comment 1

[Alex Thayer [:alexical] (she/her)]

I should clarify here - we do have _scheduleArbitrarilyLateIdleTasks, which does seem to accomplish the goal of not running things during startup. However it seems that things scheduled via _scheduleArbitrarilyLateIdleTasks are not at all guaranteed to actually run eventually. And looking over telemetry, it seems it happens rather frequently that we do not run them. This makes it unsuitable for things which we do want to ensure we eventually run. It also is unsuitable for things that we want to run fairly soon, just not before the first content settles.

Comment 2

[Zibi Braniecki [:zbraniecki][:gandalf]]

I'm trying to cross-check this new event against my bootstrap proposal from 2y ago.

In my proposal I suggested the following stages:

0. Initialized
1. First Paint
2. First Confluent Paint
3. Visually Completed Paint
4. Chrome Interactive
5. Fully Loaded

The intention for this model was to intertwine two sides (engine vs app) in a two-way communication allowing the app to wait for the engine, but also for the engine to optimize against app bootstrapping.

The event you're adding here seems to be either (4) or (5), and I think it would be useful to further specify which one it is.

I'll describe the difference:

4. Chrome Interactive gets fired when the UI of the app is fully usable, and it is expected that tasks initialized by that event will not affect the sense of the visual settlement or basic interactivity by the user. User can click on each button, scroll, and so on.

A good example of what might go here is a pre-load of a data needed for common, but user-activated operations. For example address bar history may be loaded now, because visually the UI is complete, event observers are attached to the address bar, and if the user will click on it, the drop-down will be waiting for that load.
Since we expect the user to click on the addressbar most of the time, we may eagerly trigger this data fetch now, and in result when the user activates the address bar, the history will be available sooner.

5. Fully Loaded is an event intended to inform us that the startup has completely settled. This is the moment where we expect that without further user interaction and until some scheduled timers kick off, no activity is going to happen. No further loads after this point, no further modules to auto-initialize.
   This stage is mostly useful for the engine to perform initial GC/CC, for integration tests to measure memory, time-to-fully-loaded, potentially cache some parts of the memory to speed up load next time and maybe submit telemetry.

Comment 3

[Emma Malysz]

Attachment: Bug 1637024: notify observers once startup has settled to begin running deferred tasks.

We consider startup settled at the point where MozAfterPaint events have not caused
a Browser:FirstPaint message to be sent for a period of time.
This tracks the amount of time in between Browser:FirstPaint messages.
It also tracks the amount of time elapsed as a fallback if there are consistent messages.
Whichever time limit is hit first is where startup has settled and
will kick off the deferred tasks, which are scheduled using an idle callback.

Comment 4

[Emma Malysz]

Attachment: Bug 1637024, use first contentful paint to kick off deferred tasks

Comment 5

[Emma Malysz]

Attachment: Bug 1637024: utilize a StartupSettledNotifier module to defer expensive work in about:home startup.

When the components feed of about:home is loaded, startup is considered settled. This will help
defer expensive tasks until after that point.