Closed Bug 871823 Opened 11 years ago Closed 10 years ago

Launch latency of Contacts application needs to be improved


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



(blocking-b2g:koi+, b2g18+, b2g-v1.2 fixed)

blocking-b2g koi+
Tracking Status
b2g18 + ---
b2g-v1.2 --- fixed


(Reporter: mvikram, Assigned: kgrandon)



(Keywords: perf, Whiteboard: [c= p=4 s= u=1.2])


(3 files)

18.80 KB, application/octet-stream
150.61 KB, application/octet-stream
293.42 KB, application/octet-stream
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.          2225                                            
QRD B2G AU01.          2460                                       
QRD B2G AU01.        2213                                       
QRD B2G AU01.        2290

Expected results:

We would like to see the launch time improved to ~1500 ms.
blocking-b2g: --- → leo?
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?
Flags: needinfo?(mvikram)
Keywords: perf
Whiteboard: c=
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.
Flags: needinfo?(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 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.
Flags: needinfo?(jhylands)
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.
blocking-b2g: leo? → koi?
tracking-b2g18: --- → +
Attached file 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):

                  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
Flags: needinfo?(mvikram)
Attached file Database for 1 contact
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.
Depends on: 865750, 871445
Ever confirmed: true
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.
QA Contact: bkelly
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.
No longer depends on: 865750, 879299
Assignee: nobody → bkelly
QA Contact: bkelly
Priority: -- → P2
Whiteboard: c= → c= p=4 ,
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.

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

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.
Depends on: 879299
I've rebased my work-in-progress branch to master now that bug 879299 has landed.
Whiteboard: c= p=4 , → [ c= p=4 s=2013.08.09 ]
Blocks: 896835
comms-triaged: performance team to triage and consider this for v1.2 or not
Whiteboard: [ c= p=4 s=2013.08.09 ] → [ c= p=4 s=2013.08.09 ][comms-triaged]
Whiteboard: [ c= p=4 s=2013.08.09 ][comms-triaged] → [c= p=4 s= u=1.2] [comms-triaged]
blocking-b2g: koi? → koi+
Priority: P2 → P1
Whiteboard: [c= p=4 s= u=1.2] [comms-triaged] → [c= p=4 s= u=1.2]
Depends on: 905771
Assignee: bkelly → kgrandon
Depends on: 907907
Depends on: 909935
Blocks: 913775
Blocks: 914913
Depends on: 919591
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.
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.