Closed Bug 1086963 Opened 8 years ago Closed 7 years ago
[meta] Gallery app launch latency is worse than Android on quad core device
We are seeing following launch latency numbers for gallery : FFOS v2.1 : 1117 ms Android : 669 ms Device used : msm8926 quadcore RAM: 1GB It is showing that 2 cpu cores are mostly idle during app launch. We are tracking it for v2.2
8 years ago
blocking-b2g: --- → 2.2?
Summary: Galley app launch latency is worse than Android on quad core device → Gallery app launch latency is worse than Android on quad core device
Being tracked as part of multi-core performance improvements: https://bugzilla.mozilla.org/show_bug.cgi?id=1093564
blocking-b2g: 2.2? → ---
We should divide this topic into 2: Gecko and Gaia. Thinker, can you do that?
Looks like we have these bugs already. Clear ni.
Summary: Gallery app launch latency is worse than Android on quad core device → [meta] Gallery app launch latency is worse than Android on quad core device
please remove 2.2+ since this bug is not in the scope.
As discussion with Kevin and Ken, this is in v2.2 feature scope. Marked this for scope tracking.
Our understanding is that Thinker's team is working on gecko level changes that may improve the app start-up time on quad core. Any recommendation on the gaia side for gallery? Thinker: Do we have launch latency results for gallery with the gecko optimizations on quad core device? Thanks for your help!
QA team has a report for Nexus 5.
(In reply to Hema Koka [:hema] from comment #6) > Our understanding is that Thinker's team is working on gecko level changes > that may improve the app start-up time on quad core. Any recommendation on > the gaia side for gallery? > > Thinker: Do we have launch latency results for gallery with the gecko > optimizations on quad core device? Thanks for your help! You may need this data. FYI. - https://docs.google.com/a/mozilla.com/spreadsheets/d/1Hk9kWld3ZdzFxG3vS5au0sepm7eLv2_7BS2Kn3N8Z-A/edit#gid=9028135 Gallery cold launch time (Visually complete): @ Workload: 20 gallery images (make reference-workload-light) - Flame 2.1 (Dual-Core & 1024 MB): 1019.9 ms - Flame 2.1 (Single-Core & 319 MB): 1635.5 ms - Nexus 2.2 (Quad-Core & 2048 MB): 721.9 ms - Madai 2.0 (Quad-Core & 1536 MB): 1057.8 ms
As part of bug 1127078, I landed two gaia changes that gave more than 100ms startup time improvement on both Nexus5-l and Flame. In my testing, the Gallery app startup time for a Nexus5-l running master is now down to 450ms on average with a median of 448ms over 50 trials. See https://bugzilla.mozilla.org/show_bug.cgi?id=1129584#c13 Bug 1129584 may give an additional 10 to 20ms improvement, but that patch involves completely rearranging the gallery app startup code and may not be suitable for uplift to 2.2 The improvement seemed to be a similar amount on the dual-core Flame and the quad-core Nexus 5. So we're still not really taking advantage of the 4 cores. Perhaps this is just because gallery app startup has a bottleneck that cannot be parallelized, or because gecko or gonk aren't properly utilizing all four cores. Needinfo Tapas so he knows about these recent changes. Tapas: the relevant Gallery app bugs are 1129563 and 1129572. Both are on master and I have requested uplift to 2.2 for both of them. I'll be interested to know whether these may a significant difference in testing of your quadcore device.
Removing the dependency on bug 1126119 because the Gallery app no longer uses mozHasPendingMessages()
No longer depends on: 1126119
Tapas, In addition to the note in comment #9, here's another question for you: can you think of any power management settings that we might tweak to get the idle cpu cores to wake up more quickly when an app is launched? Does the setInteractive() code you contributed in bug 890541 work on Lollipop or was that JB-specific? By reading /proc/stat, then lauchning the Gallery a bunch of times, then reading /proc/stat again, I can see that core 3 remains turned off most of the time and really doesn't contribute much to startup. Perhaps that is just because gecko can't parallelize the process of loading a app very well. Or maybe we are being to aggressive about power management and core 3 just doesn't get switched on fast enough to help out?
Coding effort completed. Require verification.
Status: NEW → ASSIGNED
CAF (Inder) expressed a preference to track performance meta bugs like these instead of their more granular blockers since, in their opinion, the individual blockers tend to change and don't always reflect a direct connection to the primary performance issue. CAF will track and update (close) these bugs when the reported performance issue is resolved.
Cold launch time (Visually Loaded) on Flame: Datazilla Master v2.2 v2.1 Camera 1375 1383 1634 Clock 1266 1164 1041 Contacts 860 806 883 FM Radio 627 554 542 Gallery 1000 940 969 Messages 1392 1255 1262 Music 1312 1164 929 Phone 615 554 567 Settings 2537 2573 2586 Video 1054 1022 964
Last update as followings, and Raptor dashboard . Mark worksforme per no longer 2.2 blocker. Please follow bug 1196586 in v2.5. ------------------------- appName master v2.2 -------- ------ ---- Messages 1700 986 Video 1127 1020 Settings 2682 2437 FM Radio 707 496 Gallery 1076 1046 Music 1085 956 E-Mail 463 1973 Contacts 1118 717 Clock 1202 1206 Calendar 1476 1342 Camera 1668 1297  http://raptor.mozilla.org/#/dashboard/file/raptor.json
You need to log in before you can comment on or make changes to this bug.