Open Bug 1550073 (GeckoView_Startup) Opened 1 year ago Updated 2 months ago

[meta] GeckoView startup performance


(GeckoView :: General, enhancement)

Not set


(Not tracked)


(Reporter: jesup, Unassigned)


(Depends on 12 open bugs)


(Keywords: meta, perf, Whiteboard: [qf:meta])

Startup performance of GeckoView is important; this tracks any issues related to that. This is not the metabug for all of Fenix startup performance; just the GV portion.

This does cover both applink and to-the-UI startup types, though they will have different issues, and in some cases contradictory requirements/solutions.

See for some applink startup issues. On a Pixel2, we take ~1.8 seconds to start, vs ~450ms for Chrome

Alias: GeckoView_Startup

The auto-downloaded resources mentioned in Bug 1529333 can impact startup performance.
In a simpleperf capture we did see the safebrowsing Classifier Update thread, although it looks like only 0.42% of samples in the 5 second period.

Whiteboard: [gv][qf] → [gv][qf:meta]
Type: defect → enhancement
Depends on: 1541518
OS: All → Android
Whiteboard: [gv][qf:meta] → [qf:meta]
Depends on: 1551313
Depends on: 1551890
Depends on: 1553842
Depends on: 1554183
Depends on: 1554313
Depends on: 1552183

Here's a recent profile of GeckoView-example startup on a Moto G5:
This profile was taken with a 5ms interval so that profiler overhead wouldn't distort timings too much. Here's another profile with 1ms interval, so more detail but also less representative timings:

And here are profiles from GeckoView startup in Fenix, on a Moto G5, with remote debugging disabled: (1ms sampling) (2ms) (5ms) (10ms)

Depends on: 1616399
Depends on: 1616400
Depends on: 1612961
No longer depends on: 1616399
Depends on: 1618391
Depends on: 1619032

Fenix App Link startup profile:
This one includes a bit of information about what happens in mozglue before libxul takes over, with the help of the BaseProfiler (bug 1557570). I see 20-40ms in CustomElf::Relocate and 16-20ms reading /proc/self/maps in EnsureWritable::getProt. Overall, there's nothing concerning standing out to me in the pre-libxul part.

Fenix App Link startup, captured by simpleperf
The build is a taskcluster performanceTest.
App link intent sent from adb.

Fennec68release applink startup simpleperf profile via the same method, for comparison

Depends on: 1620105
Depends on: 1620111
Depends on: 1620415
Depends on: 1620445
Depends on: 1620447
No longer depends on: 1620105
Depends on: 1621340
No longer depends on: 1551313
Depends on: 1623505
Depends on: 1623518
Depends on: 1623521
Depends on: 1620079

Recent Fenix Nightly App link startup profile:

Depends on: 1623758
Depends on: 1623772
Depends on: 1623925
No longer depends on: 1623521
Depends on: 1624464

Recent Fenix Nightly App link startup profile:

Depends on: 1626816

Recent Fenix Nightly App link startup profile:

Bug 1621340, bug 1618391 and bug 1623518 remain the lowest hanging fruit I can see. After that, possibly bug 1231711 to help with bug 1623521.

Recent Fenix Nightly App link startup profile:

This includes the fix for bug 1602318. You can see that the first "" load is started in the parent process before it is started in the content process, and overall slightly earlier (20-100ms). However, it doesn't have a huge effect in this particular run because the network responses come from the cache and because add-ons code is keeping the parent process main thread busy.
There still seems to be quite a lot of potential to move the first network load earlier. The first call to loadURI (in GeckoViewNavigation.jsm) runs about 570ms before the first network request to is started:

Recent Fenix Nightly App link startup profile:

You need to log in before you can comment on or make changes to this bug.