1949978 - Investigate how to flush StartupCache for mobile app-link performance test

Status: RESOLVED FIXED

(Core :: Performance Engineering, task)

Description

[Ted Campbell [:tcampbell]]

As part of Bug 1618391, we noticed that the gecko "StartupCache" typically doesn't flush until about 1-2min after browser starts. For the purpose of testing, Bug 1631991 added a shorter timeout for GTest configurations though that doesn't apply to our applink startup perf test.

We should consider if waiting a full minute to get a startupcache flush is still the right move, especially on Android where user behaviour can be frenetic. A potential thing to consider is being more aggressive with flush if the cache doesn't exist at all yet. With the ScriptPreloader we added a flush to browser startup idle and there haven't been complaints about that extra I/O, so having startup cache flush at same time seems reasonable.

Comment 1

[Ted Campbell [:tcampbell]]

On desktop, we use the shutdown event to help handle cases were we close before the standard timer, but that doesn't apply as much to Android where we don't have such clean shutdowns.

Additionally, the ScriptPreloader flushing at the end of each startup is probably too aggressive and we need a different schedule for that on mobile.

Comment 2

[Denis Palmeiro [:denispal]]

The current delay is set to 60s:

static uint8_t STARTUP_CACHE_WRITE_TIMEOUT = 60;

We should investigate flushing this cache at an earlier time as long as it doesn't interfere with the startup path too much.

Comment 4

[Jonathan Almeida [:jonalmeida]]

Triage: Possible duplicate.

Comment 5

[Markus Stange [:mstange]]

(In reply to Jonathan Almeida [:jonalmeida] from comment #4)

Triage: Possible duplicate.

Not a duplicate - ScriptPreloader and StartupCache are two distinct mechanisms.

Comment 6

[Markus Stange [:mstange]]

I'll look into this. I think we can just add an "early write" if no cache file exists.

Comment 7

[Markus Stange [:mstange]]

Attachment: Bug 1949978 - Do an early write of the startup cache if no cache file is present. r=tcampbell

This will make Firefox behavior in our performance CI tests more realistic:
These tests perform a warmup run which is killed before the regular
StartupCache write occurs. We don't really want to increase the time for
the warmup run, and I believe the behavior introduced in this patch makes
sense regardless - if there's no cache, writing out an incomplete cache
is better than waiting for more complete data and failing to write it out.

Comment 8

[Markus Stange [:mstange]]

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

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/0528dda2c7ef
https://hg.mozilla.org/integration/autoland/rev/757bb8c56ba8
Do an early write of the startup cache if no cache file is present. r=tcampbell

Comment 10

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/757bb8c56ba8