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
This is a meta bug to keep bugs about application startup time improvement.
Summary: [meta] Improve application startup time on multicore devices → [meta] Investigate and improve application startup time on multicore devices
(We have a meta bug to remove all sync messaging happening during app startup, but I can't find it now.)
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.
Per discussion with Ravi and Ken.
User Story: (updated)
I've created an etherpad at https://etherpad.mozilla.org/FxOSQuadCoreOptimization for collecting ideas about quadcore optimization
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.
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 | +----------+--------+--------+
I'll concentrate on Gecko as Gaia seems is going to have an architecture change in V3.
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
The latest profile  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.  http://people.mozilla.org/~bgirard/cleopatra/#report=9ca00bbd19a1585f5e3cbeb8a624da404ccbc6c4 Gecko: https://hg.mozilla.org/mozilla-central/rev/1af1b4e1c35a Gaia: d22b4cd9d7a90fcd772bc9793fb0104eff019a41
4 years ago
No longer depends on: 1147048
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.
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.