1110590 - (AppStartup) [meta] Improve application startup performance

Status: RESOLVED INCOMPLETE

(Firefox OS Graveyard :: Performance, defect, P1)

Description

[Ting-Yu Chou [:ting] (away)]

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

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

(We have a meta bug to remove all sync messaging happening during app startup, but I can't find it now.)

Comment 2

[Thinker Li [:sinker]]

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.

Comment 3

[Bobby Chien]

Per discussion with Ravi and Ken.

Comment 4

[David Flanagan [:djf]]

I've created an etherpad at https://etherpad.mozilla.org/FxOSQuadCoreOptimization for collecting ideas about quadcore optimization

Comment 5

[David Flanagan [:djf]]

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.

Comment 6

[David Flanagan [:djf]]

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.

Comment 7

[Ting-Yu Chou [:ting] (away)]

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

Comment 8

[Ting-Yu Chou [:ting] (away)]

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.

Comment 9

[Ting-Yu Chou [:ting] (away)]

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

Comment 10

[Ting-Yu Chou [:ting] (away)]

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

Comment 11

[Ting-Yu Chou [:ting] (away)]

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

Comment 12

[Ting-Yu Chou [:ting] (away)]

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

Comment 13

[Ting-Yu Chou [:ting] (away)]

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

Comment 14

[Ting-Yu Chou [:ting] (away)]

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.