1349840 - Start preloading content processes early during statup

Status: NEW

(Core :: DOM: Content Processes, enhancement, P3)

Description

[(no longer active)]

See this profile: <https://perfht.ml/2n9y0eq>

We wait a long time before starting the content process, is there a good reason for this?  Why not at least start one content process much earlier so that by the time that we actually will get blocked on needing it, it will hopefully be ready?

Comment 1

[Mike Conley (:mconley) (:⚙️)]

This seems kind of at odds with something that Enn is looking at doing in bug 1356561.

We should probably come to a conclusion on the best approach here.

Comment 2

[Jens Stutte [:jstutte]]

Hi Randell, I can imagine that we made some progress here (or know our limitations better) in the meantime ?

Comment 3

[Randell Jesup [:jesup] (needinfo me)]

We create preallocated processes off of Mainthread Idle - though since starting a process can take a couple of hundred ms, that fact that we've been idle for (say) 20ms may not be a good indicator that it's a good time to start preallocated process creation. We've already created the window skeleton by the time we instantiate the PreallocatedProcessManager, and a while later we call ::Enable(), which calls AllocateAfterDelay(true), which eventually calls AllocateOnIdle().

AllocateAfterDelay(true) imposes a 1s delay before looking for idle time. This was set a while ago... and of course it's probably too long for high-end machines, and perhaps too short for low-end machines, assuming it's still applicable.

Mike, Bas, Olli, thoughts?

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

I assume at that point we have usually created at least one child process for the foreground tab, and then we will create more processes when needed . And if we create the rest of the (preallocated) child processes on idle, the setup sounds quite reasonable to me.
We don't want to create preallocated child processes while we're very busy with other stuff, I think.

Comment 5

[Randell Jesup [:jesup] (needinfo me)]

Correct; the question is "is 1s after the first GetBrowsingContext() call a good time to start looking for Idle to start preallocating more content processes. We create the first ContentProcess at the same point we start the 1s preallocation timer when we create a LoadContext and do GetBrowsingContext(). These are called from _setupInitialBrowserAndTab(). So the question would be "is when we call setupInitialBrowserAndTab() a good point, or should we try to create a process earlier so it's available (hopefully) at that point. (At the risk of slowing down other startup stuff that might be visible).

Side question: should we adjust the 1s number?

Comment 6

[Mike Conley (:mconley) (:⚙️)]

So in my mind, the priority of process launch at startup should be something like:

1. Parent process
2. Compositor process
3. Content process
4. WebExtension process
5. Networking process

Where I believe we need the first two in order to present anything to the user on screen. Once the paint of the browser UI is done, we should do our best to get the content and WebExtension processes launched because that's going to block presenting either the default about:home or whatever homepage the user has set. After that, I think 1s is probably a fine amount of time to start waiting for idle for more content process launching.

We might be getting a little off of the target of this bug. The original profile is 5 years old, and the startup pathways of Firefox have changed significantly. Looking at the source of _setupInitialBrowserAndTab and surrounding, it looks like we call into that once the DOM of the initial window has been loaded, and that's probably the right place. My worry about loading it any sooner is accidentally having it get in the way of presenting the browser UI, which is the first priority when launching.

Comment 7

[Randell Jesup [:jesup] (needinfo me)]

We can probably be more aggressive at starting processes if we have a bunch of cores (something else that has generally changed in the last 5 years); we could make when we call it depend on cores. It does use some time on mainthread, but it's not clear exactly how much. Generally OS process creation is the long pole here.

Comment 8

[Bas Schouten (:bas.schouten)]

In my opinion an important thing to address here is to have something more of a 'deep idle' state that is better at detecting what the right time is to do these kinds of things.