1392679 - (iphone5c-perf) [meta] iPhone 5C app startup can be 20sec

Status: RESOLVED INVALID

(Firefox for iOS :: General, enhancement)

Description

[:garvan]

Attachment: 20sec-startup-time.mov

See video showing 20 seconds until the UI is interactive.
This is reproducible cold boot problem on iPhone 5C when booting to the history screen.
I am signed in to sync.

Comment 1

[Richard Newman [:rnewman]]

https://blog.automatic.com/how-we-cut-our-ios-apps-launch-time-in-half-with-this-one-cool-trick-7aca2011e2ea

might be relevant.

See also Bug 1391837.

Comment 2

[:garvan]

Attachment: 5s in some DB code on main thread at startup

Comment 3

[:garvan]

Bug 1387181 (DB ops on main thread) is contributor to this problem
Attached is profile showing 5s along in a main-thread db block of code.

That blog post looks highly anecdotal, profiling shows we are spending all our startup time in actual code, any app I have worked on has been the same.

Comment 4

[Justin D'Arcangelo [:justindarc]]

Changing this into a meta bug for tracking all the individual bugs to work towards improving this.

Comment 5

[:garvan]

The profile on this bug shows a full 5 seconds being spent in Activity Stream

Comment 6

[Richard Newman [:rnewman]]

Update from Slack: Garvan found that if we put a `fatalError` at the start of the app delegate, our splash screen stays on screen for 7.5 seconds.

dyld logging says about 5 seconds.

So his terrible 11-second startup is:

5.1 seconds dynamic linking
2.4 seconds other pre-main work (rebasing?)
4 seconds app startup (much of it in BVC)

I think that implies that Comment 1 is relevant after all, and that we also need to work on early-stage startup app code.

Comment 7

[:garvan]

Now that we have the AS off-main(Bug 1395265), we can look for the next hotspot.

I am going to guess that dylib load time is relatively stable, and assume the remaining 15 sec was stuck in disk writes. 
When this bug was happening, I later saw I was down to near-zero disk space. So if we want to dig into this exact case more, we need to run in that state.

My 5C is 8GB device, which the OS takes up nearly the entire storage, so it always runs with minimal free space.

Comment 8

[Justin D'Arcangelo [:justindarc]]

(In reply to :garvan from comment #7)
> When this bug was happening, I later saw I was down to near-zero disk space.
> So if we want to dig into this exact case more, we need to run in that state.
> 
> My 5C is 8GB device, which the OS takes up nearly the entire storage, so it
> always runs with minimal free space.

We might not want to use this as a target for profiling since it might artificially inflate the times in certain areas of the app if we end up thrashing I/O by aggressively swapping to disk. I think the 5C or SE might be a good baseline device for profiling, but we probably want to ensure that we at least have 500MB of free disk space.

Comment 9

[:garvan]

Yeah, not for our baseline perf testing, but as part of stress testing (or would this be called a load test). Very possible to run iPhone with minimal free storage and let iCloud swap things and out to free up space.

Comment 10

[Jean Gong :jgong]

Garvan, QF triage team to ping iOS team for further triage.

Comment 11

[:garvan]

We can close this as:

• extensive perf improvements since this was filed
• iPhone 5C (and all 32-bit devices) no longer supported, 64-bit devices are performant and not exhibiting this problem