Report: 2015/08/18 Flame-KK 319MB ------------------------- appName master v2.2 -------- ------ ---- Messages 1545 986 Settings 2669 2437 Video 1182 1020 Gallery 1139 1046 Music 1054 956 FM Radio 741 496 E-Mail 547 1973 Contacts 1149 717 Clock 1395 1206 Calendar 1543 1342 Camera 1465 1297 Dialer 769 Aries-KK 2G ---------------------------------------------------------------------- appName value memory device branch context -------- ----- ------ ------ ------ ----------------------------- Calendar 730 2048 aries master calendar.gaiamobile.org Contacts 565 2048 aries master communications.gaiamobile.org FM Radio 349 2048 aries master fm.gaiamobile.org E-Mail 250 2048 aries master email.gaiamobile.org Music 511 2048 aries master music.gaiamobile.org Clock 518 2048 aries master clock.gaiamobile.org Camera 651 2048 aries master camera.gaiamobile.org Dialer 305 2048 aries master communications.gaiamobile.org Video 710 2048 aries master video.gaiamobile.org Settings 1657 2048 aries master settings.gaiamobile.org Gallery 507 2048 aries master gallery.gaiamobile.org Messages 778 2048 aries master sms.gaiamobile.org

Need profiling data to follow up.

Profile result https://people.mozilla.org/~bgirard/cleopatra/#report=85f71f0732eeaf669fa588f82417aefc04cf89b3 We can see from firstLoadURI to visuallyLoaded about 1.7s we could split it to six big chunks: 0. 206ms Some random stuff. Some nsIApplication activity is notable. 1. 363ms Loading JavaScript and running it. I don't know what gaia_build_defer_index.js is for yet. 2. 172ms Still running script and gaia_build_defer_index.js again. Looks like gaia header because I saw runFontFitSoon 3. 349ms Received something from XHR and started to process it. Looks like l10n because I saw onL10nLoaded() 4. 344ms Idle and refresh triggered by vsync, probably waiting DeviceStorage or IDB response 5. 154ms Received result from IDB and starting to add video thumbnails to the list. Above six sums up to 1588ms total.

One block is 191ms of sync ipc message IPDL::PHal::SendGetCurrentSwitchState. Filed bug 1197689.

https://people.mozilla.org/~bgirard/cleopatra/#report=d022fd8c5ab70e0fea4c34d6d77e667bea6c9e8f&filter=[{%22type%22%3A%22RangeSampleFilter%22,%22start%22%3A68080,%22end%22%3A69084}]&selection=0,1014,4 New profile after fixing AudioChannelManager and removing gaia-header. We could find 1. IndexedDB and DeviceStorage initialization is delayed by b2g main thread by about 150ms. If we could make the mozbrowserloadend handling less heavy we might reduce this part. 2. We still spent about 200ms parsing and run JavaScript. Maybe we could lazyload more js file we might reduce this part. 3. Populating thumbnail list takes about 130ms. No idea off hand how to improve this. 4. After recv LoadURL we spent about 200ms doing something before we start parsing index.html and scripts. Not sure where to optimize yet.

coldlaunch.visuallyLoaded ------------------------- appName master v2.2 -------- ------ ---- Video 1258 1020 ---------------------------------------------------------------------- appName value memory device branch context -------- ----- ------ ------ ------ ----------------------------- Video 696 2048 aries master video.gaiamobile.org

I see some action items can be done from gaia: 1. Initialize mediaDB as early as possible 2. Use gaia-header optimizations like bug 1198132

(In reply to Ting-Yu Chou [:ting] from comment #7) > I see some action items can be done from gaia: > > 1. Initialize mediaDB as early as possible As I explained in bug 1210860 [1], initDB() is being called as early in the startup process as it can be -- as soon as we get the `mozL10n.once` callback. It can't be called before then as the db initialization process displays localized text in some circumstances. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1210860#c23 > 2. Use gaia-header optimizations like bug 1198132 I will make these changes and test to see what performance impact there is. Have you discussed this bug with Ting? It seems this bug and bug 1210860 are very similar.

This is a patch that adds the gaia-header optimizations like bug 1198132. In my testing, I didn't see a significant performance improvement. Perhaps you can test it also.

With attachment 8675191 [details] [diff] [review], I can see >70ms from running gaia-header font fit before visuallyLoaded is gone. [1] Before: http://people.mozilla.org/~bgirard/cleopatra/#report=8c6f92fc1dafeed2340a52858b7145678f96c253&search=gaia-header [2] After: http://people.mozilla.org/~bgirard/cleopatra/#report=105ee7ad9bba7c235ea768fda958e991272dd979&search=gaia-header

(In reply to Ting-Yu Chou [:ting] from comment #10) > With attachment 8675191 [details] [diff] [review], I can see >70ms from > running gaia-header font fit before visuallyLoaded is gone. > > [1] Before: > http://people.mozilla.org/~bgirard/cleopatra/ > #report=8c6f92fc1dafeed2340a52858b7145678f96c253&search=gaia-header > [2] After: > http://people.mozilla.org/~bgirard/cleopatra/ > #report=105ee7ad9bba7c235ea768fda958e991272dd979&search=gaia-header Note the profiles were captured on an Aries.

(In reply to Russ Nicoletti [:russn] from comment #8) > (In reply to Ting-Yu Chou [:ting] from comment #7) > > I see some action items can be done from gaia: > > > > 1. Initialize mediaDB as early as possible > > As I explained in bug 1210860 [1], initDB() is being called as early in the > startup process as it can be -- as soon as we get the `mozL10n.once` > callback. It can't be called before then as the db initialization process > displays localized text in some circumstances. In theory, you can launch initDB before l10n is done if you guard the displaying function to make sure that it is fired only after l10n is ready. So instead: l10n.ready then initDB then display initDB then l10n.ready then display It should be faster because initDB and l10n will be parallelized.

Please reopen if you need.