1960752 - Preallocate GPU and WebExtension processes in addition to tab process when FLAG_PRELOAD_CHILD is set

Status: REOPENED

(GeckoView :: General, enhancement, P1)

Description

[Markus Stange [:mstange]]

On startup, if FLAG_PRELOAD_CHILD is set, the "Java" side of GeckoView speculatively creates a tab process. Then, when Gecko later asks for a process of that type, it can use this preallocated process. This absorbs some of the process startup overhead.

We currently only do this for a single tab process. However, we see similar delays for the GPU process (bug 1958097) and the WebExtension process (bug 1958327). We need all three child processes to actually load and display a web page during startup.

So I think we should change this code to preallocate all three process types, i.e. all the child processes needed to display a web page.

Comment 1

[Markus Stange [:mstange]]

Attachment: Bug 1960752 - Preallocate WebExtension process and GPU process on the Java side. r=#geckoview-reviewers

Comment 2

[Markus Stange [:mstange]]

Profiles:
Before: https://share.firefox.dev/3EaVCLV (120ms blocking in ContentParent::CreateBrowser for the WebExtension process)
After: https://share.firefox.dev/4igFO8g (nearly no blocking in ContentParent::CreateBrowser)

Comment 3

[Markus Stange [:mstange]]

https://treeherder.mozilla.org/jobs?repo=try&revision=ceeb5058c5e3a45c493e7093f30fdc8f9033c563

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7cb8beb3cf27
Preallocate WebExtension process and GPU process on the Java side. r=geckoview-reviewers,nalexander

Comment 5

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/7cb8beb3cf27

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/51f418827291
Revert "Bug 1960752 - Preallocate WebExtension process and GPU process on the Java side. r=geckoview-reviewers,nalexander" to address the performance regression in bug 1966109.

Comment 7

[Iulian Moraru]

Revert to address the performance regression in bug 1966109.

• Push that was backed out

• Backout link

Comment 8

[Pulsebot]

Revert to address the performance regression in bug 1966109.

Pushed by [e-mail]:
https://hg.mozilla.org/releases/mozilla-beta/rev/ba76d6689be7
Revert "Bug 1960752 - Preallocate WebExtension process and GPU process on the Java side. r=geckoview-reviewers,nalexander" to address the performance regression in bug 1966109

Comment 9

[Markus Stange [:mstange]]

I asked for this to be backed out because it didn't result in any improvement on our tests, and because it made the first UI layout slower, probably because we're running more CPU work than we have CPU cores during the early part of startup.

I'm working on other app link startup improvements that may make this worthwhile in the future, so at that point we should try to reland this.

Pasting what I wrote in bug 1966109 comment 6:

[...] I think what happens in that creating new processes takes up CPU resources, causing the Android UI startup work to slow down. The profiles I linked to in bug 1960752 comment 2 actually show this, if you look at what executes on the Android UI thread up to the end of org.mozilla.fenix.HomeActivity.onStart:

Before: https://share.firefox.dev/3SYdRrs (174ms in onStart)
After: https://share.firefox.dev/3SoWcZO (217ms in onStart, ~40ms longer)

The goal was to reduce the overall time for the web page to become visible during app link startup. Unfortunately, it looks like the patch didn't contribute to that goal either: This graph of newssite-applink-startup times on the Pixel 6 remains rather flat around April 29.

I think the delays from process initialization just aren't on the critical path at the moment.

Given the fact that this regression isn't balanced by any improvement I can find, it's probably worth backing out this patch until we get to a point where it makes a difference that is actually visible in our tests. Then, once we get to that point, we can reland it and say "yes, first UI visible gets slightly slower, but full applink startup becomes faster".

Comment 10

[Markus Stange [:mstange]]

Backout merged to central: https://hg.mozilla.org/mozilla-central/rev/51f418827291383ab8998a5a20ff1d2072d7340e

Comment 11

[Markus Stange [:mstange]]

The backout actually did affect the newssite-applink-startup test on the Pixel 6: It regressed from ~1250ms to ~1450ms.

So now I'm thinking it probably caused an improvement when it originally landed, we just didn't have enough data points on the Pixel 6 to notice the improvement. Due to capacity issues we only run the test on the Pixel 6 on mozilla-central, not on autoland.

Comment 12

[Acasandrei Beatrice (needinfo me)]

(In reply to Pulsebot from comment #6)

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/51f418827291
Revert "Bug 1960752 - Preallocate WebExtension process and GPU process on
the Java side. r=geckoview-reviewers,nalexander" to address the performance
regression in bug 1966109.

Perfherder has detected a mozperftest performance change from push 51f418827291383ab8998a5a20ff1d2072d7340e.

Markus, could you please help confirming whether the following performance change was indeed caused by the backout? Some jobs are failing to run, and it is challenging to identify the culprit.

Regressions:

Ratio	Test	Platform	Options	Absolute values (old vs new)
5%	foreground-resource pss-crashhelper-end	android-hw-a55-14-0-aarch64-shippable		19,257.75 -> 20,179.92
5%	foreground-resource pss-crashhelper-10%	android-hw-a55-14-0-aarch64-shippable		19,128.08 -> 19,988.92
4%	foreground-resource pss-crashhelper-start	android-hw-a55-14-0-aarch64-shippable		19,096.46 -> 19,926.75
4%	foreground-resource pss-crashhelper-50%	android-hw-a55-14-0-aarch64-shippable		19,225.67 -> 20,043.00
2%	applink-startup-navigation-start cold_view_nav_start.mean	android-hw-a55-14-0-aarch64-shippable		874.05 -> 894.74
2%	applink-startup-navigation-start cold_view_nav_start.median	android-hw-a55-14-0-aarch64-shippable		869.21 -> 888.54

Improvements:

Ratio	Test	Platform	Options	Absolute values (old vs new)
40%	foreground-resource rss-tab-start	android-hw-a55-14-0-aarch64-shippable		302,124.33 -> 182,592.67
39%	foreground-resource rss-tab-50%	android-hw-a55-14-0-aarch64-shippable		303,924.67 -> 184,067.67
39%	foreground-resource rss-tab-end	android-hw-a55-14-0-aarch64-shippable		303,924.67 -> 184,067.67
39%	foreground-resource rss-tab-10%	android-hw-a55-14-0-aarch64-shippable		303,189.00 -> 183,829.67
39%	background-resource rss-tab-start	android-hw-a55-14-0-aarch64-shippable		301,251.67 -> 183,017.33
...	...	...	...	...
9%	background-resource cpuTime-tab-50%	android-hw-a55-14-0-aarch64-shippable		1,618.33 -> 1,465.00

If you have any questions or need any help with the investigation, please reach out to a performance sheriff. Alternatively, you can find help on Slack by joining #perf-help, and on Matrix you can find help by joining #perftest.

Details of the alert can be found in the alert summary, including links to graphs and comparisons for each of the affected tests.

If you need the profiling jobs you can trigger them yourself from treeherder job view or ask a performance sheriff to do that for you.

You can run all of these tests on try with ./mach try perf --alert 45344

The following documentation link provides more information about this command.