This is a meta bug to keep bugs about application startup time improvement.

(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.

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 | +----------+--------+--------+

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.

(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.

(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.

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 [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

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.