I've attached patches which reduce the time during Fenix startup between the creation of the Gecko thread in the first content process and the call to `GeckoThread.initGeckoEnvironment`. These patches depend on bug 1937836 - they only affect behavior if `dom.ipc.processPrelaunch.enabled` is `true`, because they use the PreallocatedProcessManager. However, in the process of writing an explanation of why these patches are needed, I realized that they aren't all that useful at the moment. My goals were: 1. Reduce the time that the parent blocks while waiting for the child process handle. 2. Make the content process available to accept data from the network earlier, by front-loading initialization work. And yes, the patches achieve these goals, but they don't achieve a reduction of the applink startup time. About goal 1: In bug 1958065 I was reporting "varying" times of blocking in the parent, sometimes around 30ms. I can't really reproduce those times anymore; I wonder if it was just unfortunate thread scheduling. It turns out that `GeckoChildProcessHost::WaitForProcessHandle` is really quite short in most cases, below 10ms. It only takes a long time if the native Android process hasn't been created yet. But for the first content process, [we preallocate the native process on the Java side](https://searchfox.org/firefox-main/rev/ee102e926521b3e460293b0aea6b54b1a03f6f74/mobile/android/geckoview/src/main/java/org/mozilla/gecko/GeckoThread.java#492-495), so getting the process handle is quick for this first content process. (The WebExtension process is another matter, bug 1958327.) About goal 2: Preallocating a process from the Gecko side doesn't actually front-load all that much work. Without LaunchSubprocessResolve, all it gets us is dlopen("libxul.so") and `InitXPCOM`, [which altogether takes 50ms](https://share.firefox.dev/4g1JTh2) or less. And with LaunchSubprocessResolve, it also front-loads about [about 70ms of ContentChild initialization work](https://share.firefox.dev/4oZdoUH). But there's not much point to front-loading content process work because the content process is not the bottleneck during applink startup. And what's worse, moving the CPU work earlier can take up CPU resources that the parent process needs for more critical work, such as drawing the URL bar or kicking off the network request. For reference, here are a bunch of profiles I grabbed with various combinations of these patches: Android profiles: [before these patches (but with dom.ipc.processPrelaunch.enabled set to true)](https://share.firefox.dev/461tSDh) [with early PreallocProcessManager initialization](https://share.firefox.dev/4mAdpNb) [with AllocateNow, blocking in ContentParent::LaunchSubprocessResolve](https://share.firefox.dev/4oTpyi5) [with immediate MakePreallocProcess() call, no sync blocking in ContentParent::LaunchSubprocessResolve](https://share.firefox.dev/3UIbj1E) [with immediate MakePreallocProcess() call and early gfxPlatform::Init](https://share.firefox.dev/4mRZCl1) [with immediate MakePreallocProcess() call and early gfxPlatform::Init and Java-side preallocation](https://share.firefox.dev/4p3055S) macOS profiles: [before these patches](https://share.firefox.dev/4oTylR7) [with early PreallocProcessManager initialization](https://share.firefox.dev/4n9jz7a) [with AllocateNow, blocking in ContentParent::LaunchSubprocessResolve](https://share.firefox.dev/45SF7Oe) [with immediate MakePreallocProcess() call, no sync blocking in ContentParent::LaunchSubprocessResolve](https://share.firefox.dev/3HTjoxy) I will remove this bug from the applink-startup list. Instead, we should focus on launching the GPU process earlier (bug 1929365), and on launching a native Android process for the WebExtension process earlier (bug 1958327).
Bug 1924849 Comment 7 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
I've attached patches which reduce the time during Fenix startup between the creation of the Gecko thread in the first content process and the call to `GeckoThread.initGeckoEnvironment`. These patches depend on bug 1937836 - they only affect behavior if `dom.ipc.processPrelaunch.enabled` is `true`, because they use the PreallocatedProcessManager. However, in the process of writing an explanation of why these patches are needed, I realized that they aren't all that useful at the moment. My goals were: 1. Reduce the time that the parent blocks while it synchronously waits for the child process handle. 2. Make the content process available to accept data from the network earlier, by front-loading initialization work. And yes, the patches achieve these goals, but they don't achieve a reduction of the applink startup time. About goal 1: In bug 1958065 I was reporting "varying" times of blocking in the parent, sometimes around 30ms. I can't really reproduce those times anymore; I wonder if it was just unfortunate thread scheduling. It turns out that `GeckoChildProcessHost::WaitForProcessHandle` is really quite short in most cases, below 10ms. It only takes a long time if the native Android process hasn't been created yet. But for the first content process, [we preallocate the native process on the Java side](https://searchfox.org/firefox-main/rev/ee102e926521b3e460293b0aea6b54b1a03f6f74/mobile/android/geckoview/src/main/java/org/mozilla/gecko/GeckoThread.java#492-495), so getting the process handle is quick for this first content process. (The WebExtension process is another matter, bug 1958327.) About goal 2: Preallocating a process from the Gecko side doesn't actually front-load all that much work. Without LaunchSubprocessResolve, all it gets us is dlopen("libxul.so") and `InitXPCOM`, [which altogether takes 50ms](https://share.firefox.dev/4g1JTh2) or less. And with LaunchSubprocessResolve, it also front-loads about [about 70ms of ContentChild initialization work](https://share.firefox.dev/4oZdoUH). But there's not much point to front-loading content process work because the content process is not the bottleneck during applink startup. And what's worse, moving the CPU work earlier can take up CPU resources that the parent process needs for more critical work, such as drawing the URL bar or kicking off the network request. For reference, here are a bunch of profiles I grabbed with various combinations of these patches: Android profiles: [before these patches (but with dom.ipc.processPrelaunch.enabled set to true)](https://share.firefox.dev/461tSDh) [with early PreallocProcessManager initialization](https://share.firefox.dev/4mAdpNb) [with AllocateNow, blocking in ContentParent::LaunchSubprocessResolve](https://share.firefox.dev/4oTpyi5) [with immediate MakePreallocProcess() call, no sync blocking in ContentParent::LaunchSubprocessResolve](https://share.firefox.dev/3UIbj1E) [with immediate MakePreallocProcess() call and early gfxPlatform::Init](https://share.firefox.dev/4mRZCl1) [with immediate MakePreallocProcess() call and early gfxPlatform::Init and Java-side preallocation](https://share.firefox.dev/4p3055S) macOS profiles: [before these patches](https://share.firefox.dev/4oTylR7) [with early PreallocProcessManager initialization](https://share.firefox.dev/4n9jz7a) [with AllocateNow, blocking in ContentParent::LaunchSubprocessResolve](https://share.firefox.dev/45SF7Oe) [with immediate MakePreallocProcess() call, no sync blocking in ContentParent::LaunchSubprocessResolve](https://share.firefox.dev/3HTjoxy) I will remove this bug from the applink-startup list. Instead, we should focus on launching the GPU process earlier (bug 1929365), and on launching a native Android process for the WebExtension process earlier (bug 1958327).