871823 - Launch latency of Contacts application needs to be improved

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Contacts, defect, P1)

Description

[Mandyam Vikram]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31

Steps to reproduce:

On measuring the first time launch latency of the Contacts app over a few builds, (please see results below), it seems to be relatively stable. However, we would like to see the latency reduced (these numbers have been captured on a QRD device).


Actual results:

Build                                      Launch time (ms)                          
QRD B2G AU01.01.00.19.050          2225                                            
QRD B2G AU01.00.01.19.070          2460                                       
QRD B2G AU01.01.00.019.077        2213                                       
QRD B2G AU01.01.00.019.086        2290



Expected results:

We would like to see the launch time improved to ~1500 ms.

Comment 1

[Andreas Gal :gal]

Dito here. Without testcase this is not actionable. We know that the contacts app launches in 600ms empty, so you are clearly measuring with some contacts preloaded. Please share _exactly_ what you are measuring. Just plain contacts? images? facebook data? other providers?

Comment 2

[Mike Lee [:mlee]]

Jon,
Please comment on where to find Contacts reference workloads and how to use them so @mvikram and others can use them when gathering and reporting performance numbers.

Comment 3

[Jon Hylands [:jhylands]]

Reference workloads for contacts can be found in the master repository. With the latest update, you can create reference workloads on either 1.1 (v1-train) or 1.2 (master) based phones.

see https://wiki.mozilla.org/B2G/QA/Tips_And_Tricks#Importing_contacts.2C_dial_data.2C_sms.2C_and_media_via_USB for details.

Note that you can use:

APPS="communications/contacts" make reference-workload-light

in order to only create contacts. There are 4 levels for reference workloads, light, medium, heavy, and x-heavy, and they create 200, 500, 1000, and 2000 contact entries respectively. Please contact me if anything isn't clear, or you need help with using reference workloads.

Comment 4

[Alex Keybl [:akeybl]]

We'll track for v1.1, we'll set koi? for v1.2 and we'll accept a low risk fix if found for v1.1.

Comment 5

[Mandyam Vikram]

Attachment: Time measurements

Here are our observations. 

We have enabled tracing within the Contacts app and output it to Logcat (we can provide a patch that turns these traces on separately). Results are in the attached spreadsheet.

To begin with, here are the steps to reproduce the results captured:
1) Flash the build on the phone
2) On rebooting the phone, launch the Contacts App
3) We have a SIM card pre-populated with about 250 contacts. Import the contacts from the SIM card (to help reproduce this scenario, I've attached two zip files of the Contacts SQLite database from the contacts app on the device, one for 1 contact and the other for 250 contacts) 
4) Exit the Contacts app
5) Launch "adb logcat | grep QCB2GTEAM" to capture trace information (assumes the build includes our patch)
6) Re-launch the Contacts app (data collected for 3 runs)
7) Measure the time from the touch event to launch the app to when the first (screen) contacts is painted
	
Please note that we also measured the launch time using a high speed camera to correlate these findings. On the average, the  camera launch latency is about ~2.1 secs for about 250 contacts (touch down to the first contact being rendered).
	
Observations (Details in attached spreadsheet):

Summary:
                  Average launch time (ms) (touch down to 1'st chunk rendered) 
1 contact                           1720
250 contacts                        1994
	
	          Average launch time (ms) (touch down to 1'st Contacts List "onListRendered") 
1 contact                           1994
250 contacts                        4059

Comment 6

[Mandyam Vikram]

Attachment: Database for 1 contact

Attached Database for 1 contact

Comment 7

[Mandyam Vikram]

Attachment: Database for 250 contacts

Attached database for 250 contacts

Comment 8

[Mandyam Vikram]

Sorry for the typo. The results should read:
	          Average launch time (ms) (touch down to 1'st Contacts List "onListRendered") 
1 contact                           1720
250 contacts                        4059

Comment 9

[Ben Kelly [:bkelly, not reviewing]]

Note, the time to "onListRendered" is related to the time being discussed over in bug 865747.  Its a bit different, though, in that onListRendered is fired after the contacts are loaded from ContactsAPI, but before they have all been rendered.  At that point the contacts have only been pushed into the toRender array.  The actual rendering can happen some time later when showNextGroup() is called either through scrolling or a timer.

I believe the plan is to improve this by using DataStore/visibility_monitor once bug 865750 and bug 871445 land.  Those changes will likely improve the initial load time for first contact as well.  Going to add those as a dependency here, although it seems maybe we need some kind of meta bug.

Comment 10

[Ben Kelly [:bkelly, not reviewing]]

And of course more investigation should be done.  This seems like relevant data, but there could be additional issues at work impacting initial startup time.

Comment 11

[Ben Kelly [:bkelly, not reviewing]]

Unfortunately the integration of visibility monitor did not help with the initial load time.  Time from Contacts.onLocalized() to rendering the first chunk stayed in the range of ~1000ms to ~1100ms.

Comment 12

[Ben Kelly [:bkelly, not reviewing]]

Plan of attack for this bug:

1) Improve LazyLoad strategy for contacts app.  Currently the list is only initialized after a large list of files is loaded.  See [1].  Initial investigation suggests this could buy us 250ms or more in time to above-the-fold display.

2) Investigate l10n lazy load improvements.  Kevin indicates he's had success with this on other apps.

3) Investigate app-side data or DOM cache.  Long term solution for this will likely be DataStore, so any work here might be throw-away.  This would likely save us around 200ms in time to above-the-fold and up to 8 or 9 seconds in total load time.

NOTE: I'm using reference-workload-heavy with 1000 contacts for all time measurements, etc.

[1]: https://github.com/mozilla-b2g/gaia/blob/master/apps/communications/contacts/js/contacts.js#L700

Comment 13

[Ben Kelly [:bkelly, not reviewing]]

Work-in-progress will be committed to this Github branch:

  https://github.com/wanderview/gaia/tree/contacts-vis-mon-load

Its based on my visibility_monitor integration working branch since I expect that to land eventually and we would probably have a lot of conflicts trying to do this work separately.

Comment 14

[Ben Kelly [:bkelly, not reviewing]]

I've rebased my work-in-progress branch to master now that bug 879299 has landed.

Comment 15

[Joe Cheng [:jcheng] (please needinfo)]

comms-triaged: performance team to triage and consider this for v1.2 or not

Comment 17

[Kevin Grandon :kgrandon]

This bug, as well as bug 914913 feel like meta bugs. Bug 914913 feels more active, so I'm going to close this one and help Ben there. We've also seen nice improvements here with the dom lazy loading.