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.

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?

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.

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.

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.

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

Attached Database for 1 contact

Attached database for 250 contacts

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

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.

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.

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.

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

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.

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

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

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.