Bug 1110590 (AppStartup)

[meta] Improve application startup performance

RESOLVED INCOMPLETE

Status

defect
P1
normal
RESOLVED INCOMPLETE
5 years ago
a month ago

People

(Reporter: ting, Assigned: bobby.chien+bugzilla)

Tracking

(Depends on 1 bug, {meta, perf})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [perf-wanted])

User Story

Acceptance Criteria:
- no regressions
- app startup time should be less than 1000 ms
- app startup time is competitive to Android on same hardware

Reference:
- https://wiki.mozilla.org/FirefoxOS/Performance/Release_Acceptance#Criteria
Reporter

Description

5 years ago
This is a meta bug to keep bugs about application startup time improvement.
Reporter

Updated

5 years ago
Depends on: 1102059
Reporter

Updated

5 years ago
Summary: [meta] Improve application startup time on multicore devices → [meta] Investigate and improve application startup time on multicore devices
Reporter

Updated

5 years ago
Depends on: 1102154
Reporter

Updated

5 years ago
Depends on: 1110624
Reporter

Updated

5 years ago
Depends on: 1110625
Reporter

Updated

5 years ago
No longer depends on: 1074783, 1082262, 1082268, 1086963
Assignee

Updated

5 years ago
feature-b2g: --- → 2.2?
User Story: (updated)
Assignee

Updated

5 years ago
feature-b2g: 2.2? → 2.2+
No longer blocks: 1074783, 1082262, 1082268, 1086963
feature-b2g: 2.2+ → ---
User Story: (updated)
(We have a meta bug to remove all sync messaging happening during app startup, but I can't find it now.)
Assignee

Updated

5 years ago
feature-b2g: --- → 2.2+
Reporter

Updated

5 years ago
Depends on: 1112989
Reporter

Updated

5 years ago
Depends on: 1087905
Reporter

Updated

5 years ago
Depends on: 1096745
Depends on: 1089920
Please remove 2.2+, since this bug is not in the scope.

For 2.2, we commit only for concrete bugs that is blocking this bug.
Flags: needinfo?(bchien)
Assignee

Updated

5 years ago
feature-b2g: 2.2+ → ---
tracking-b2g: --- → +
Flags: needinfo?(bchien)
Priority: -- → P1
Assignee

Comment 3

5 years ago
Per discussion with Ravi and Ken.
User Story: (updated)
Assignee

Updated

5 years ago
Assignee: nobody → bchien
Assignee

Updated

5 years ago
User Story: (updated)
Reporter

Updated

4 years ago
See Also: → 781613
Reporter

Updated

4 years ago
See Also: → less-js-at-startup
Reporter

Updated

4 years ago
Depends on: 1119692
Reporter

Updated

4 years ago
Depends on: 1121310
Reporter

Updated

4 years ago
Depends on: 1096782
Reporter

Updated

4 years ago
Depends on: 1121897
Reporter

Updated

4 years ago
Depends on: 1121905
Assignee

Updated

4 years ago
User Story: (updated)
Reporter

Updated

4 years ago
Depends on: 939695
Depends on: 1126119
Reporter

Updated

4 years ago
Depends on: 1126681
Reporter

Updated

4 years ago
No longer depends on: 939695
Reporter

Updated

4 years ago
Blocks: 1127189
Reporter

Updated

4 years ago
No longer blocks: 1127189
Depends on: 1127189
I've created an etherpad at https://etherpad.mozilla.org/FxOSQuadCoreOptimization for collecting ideas about quadcore optimization
Reporter

Updated

4 years ago
No longer depends on: 1127189
Reporter

Updated

4 years ago
No longer depends on: 1121905
Reporter

Updated

4 years ago
Depends on: 1130993
At Gabrielle's suggestion, I tried turning on the notify_on_migrate feature with:

adb shell echo 1 > /dev/cpuctl/apps/cpu.notify_on_migrate

On my nexus5-l running master, this one change dropped Gallery app startup time from ~450ms to ~425ms (tested over 50 runs, so I think this is a real gain).

See bug 1081871 for more on notify_on_migrate. It is not enabled by default because it was causing stability issues on Flame, I think.
In the gallery bug 1086963, I've asked Tapas at CAF whether he knows of other techniques like setInteractive() from bug 890541 that might help with startup.
Assignee

Updated

4 years ago
Depends on: 1129584
Reporter

Updated

4 years ago
Depends on: 1132861
Assignee

Updated

4 years ago
Depends on: 1133050
Assignee

Updated

4 years ago
Depends on: 1132515
Reporter

Updated

4 years ago
Depends on: 1137124
Reporter

Updated

4 years ago
No longer depends on: 1094010
Reporter

Updated

4 years ago
No longer depends on: 1137124
Reporter

Updated

4 years ago
No longer depends on: 1130993
Reporter

Updated

4 years ago
No longer depends on: 1121897
Reporter

Updated

4 years ago
No longer depends on: 1119692
Reporter

Updated

4 years ago
No longer depends on: 1126681
Assignee

Updated

4 years ago
Depends on: 1140987
Assignee

Updated

4 years ago
Depends on: 1128505
Reporter

Comment 7

4 years ago
Still gaia-header takes time during app startup, here're the numbers from the profiles (Flame 319MB) at bug 1112131 comment 40 & 41:

+----------+--------+--------+
|          | v2.2   | master |
+----------+--------+--------+
| SMS      | ~130ms | ~155ms |
| Music    | ~210ms | ~170ms |
| Gallery  | ~260ms | ~205ms |
| Contacts | ~255ms | ~390ms |
+----------+--------+--------+
Reporter

Updated

4 years ago
Depends on: 1143580
Reporter

Comment 8

4 years ago
http://blog.chromium.org/2015/03/new-javascript-techniques-for-rapid.html

Wonder how do we process defer and async script, will take a look later.
Reporter

Comment 9

4 years ago
(In reply to Ting-Yu Chou [:ting] from comment #8)
> http://blog.chromium.org/2015/03/new-javascript-techniques-for-rapid.html
> 
> Wonder how do we process defer and async script, will take a look later.

Defer script is compiled and executed on the main thread after downloaded, async script seems is compiled off main thread and executed on main thread.
Reporter

Updated

4 years ago
Depends on: 1145498
Reporter

Comment 10

4 years ago
(In reply to Ting-Yu Chou [:ting] from comment #9)
> (In reply to Ting-Yu Chou [:ting] from comment #8)
> > http://blog.chromium.org/2015/03/new-javascript-techniques-for-rapid.html
> > 
> > Wonder how do we process defer and async script, will take a look later.
> 
> Defer script is compiled and executed on the main thread after downloaded,
> async script seems is compiled off main thread and executed on main thread.

Quote Julien's bug 1093564 comment 1:

<quote>
  One idea: I think "async" scripts are now parsed in a separate thread; I don't think we use this at all in most apps because the LazyLoader we use set "async = false" to preserve script order.
</quote>

I have asked why defer scripts are not parsed off main thread in bug 906371.
Reporter

Updated

4 years ago
Depends on: 1147048
Reporter

Comment 11

4 years ago
I'll concentrate on Gecko as Gaia seems is going to have an architecture change in V3.
Reporter

Updated

4 years ago
Depends on: 1150349
Assignee

Updated

4 years ago
Alias: AppStartup
Assignee

Updated

4 years ago
Assignee

Updated

4 years ago
See Also: → 994296
Reporter

Updated

4 years ago
Depends on: 1154987
Assignee

Updated

4 years ago
Depends on: 1079585
Assignee

Updated

4 years ago
Whiteboard: [perf-wanted]
Reporter

Comment 12

4 years ago
Raptor now works with Nexus5, here're the numbers of visuallyLoaded I got from today's build with light reference workload:

Music    545.5ms
Contacts 448.450ms
Gallery  586.5ms
SMS      641.650ms

Command: RUNS=20 APP=... node tests/raptor/launch_test
Gecko: https://hg.mozilla.org/mozilla-central/rev/aad95360a002
Gaia: 5997b406e77ea726fbd9047057a1c3504f6cd6d4
Reporter

Comment 13

4 years ago
The latest profile [1] from launching SMS with light reference workload:

  - Bug 1130993 still existed and takes >40ms
  - There's a 20ms incremental GC slice [119288, 119309] right before calling Webapps.launch(), I wonder should we prohibit GC in b2g process during this critical path

BTW, I noticed Raptor measures visuallyLoaded with the timestamp of mark appLaunch, which is before Homescreen calling app.launch(), not after sending touch event.
  
[1] http://people.mozilla.org/~bgirard/cleopatra/#report=9ca00bbd19a1585f5e3cbeb8a624da404ccbc6c4
    Gecko: https://hg.mozilla.org/mozilla-central/rev/1af1b4e1c35a
    Gaia: d22b4cd9d7a90fcd772bc9793fb0104eff019a41
Reporter

Updated

4 years ago
No longer depends on: 1150349
Assignee

Updated

4 years ago
Blocks: 1180695
Assignee

Updated

4 years ago
Blocks: 1180696
Assignee

Updated

4 years ago
No longer blocks: 1180695
Assignee

Updated

4 years ago
Depends on: 1181019
Assignee

Updated

4 years ago
Depends on: 1181021
Assignee

Updated

4 years ago
Depends on: 1181023
Assignee

Updated

4 years ago
Depends on: 1181017
Assignee

Updated

4 years ago
No longer blocks: 1180696
Reporter

Updated

4 years ago
Depends on: 1194121
Reporter

Updated

4 years ago
Depends on: 1197063
Assignee

Updated

4 years ago
Depends on: 1198185
Assignee

Updated

4 years ago
See Also: → butter-delivery
Reporter

Updated

4 years ago
Depends on: 1199539
Reporter

Comment 14

4 years ago
This meta now grows to a giant, and actually not much about app startup improvement on more-core device, so filed bug 1199539 to keep them instead.

And here to keep bugs which can improve app startup no matter there're more cores or not.
No longer depends on: 1094011, 1154987, 1132861
Summary: [meta] Investigate and improve application startup time on multicore devices → [meta] Improve application startup performance
Reporter

Updated

4 years ago
No longer blocks: B2G-Multicore
Assignee

Updated

4 years ago
Depends on: less-js-at-startup
Assignee

Updated

4 years ago
Depends on: 926452
Reporter

Updated

4 years ago
Depends on: 1214516
Assignee

Updated

4 years ago
Assignee

Updated

4 years ago
Depends on: LowStorage
Assignee

Updated

4 years ago
No longer depends on: LowStorage
Assignee

Updated

3 years ago
tracking-b2g: + → ---
Assignee

Updated

3 years ago
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.