Launch latency of Contacts application needs to be improved

RESOLVED FIXED

Status

P1
normal
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: mvikram, Assigned: kgrandon)

Tracking

({perf})

unspecified
Dependency tree / graph

Firefox Tracking Flags

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

Details

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

Attachments

(3 attachments)

18.80 KB, application/octet-stream
Details
150.61 KB, application/octet-stream
Details
293.42 KB, application/octet-stream
Details
(Reporter)

Description

6 years ago
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.
blocking-b2g: --- → leo?

Comment 1

6 years ago
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)

Updated

6 years ago
Keywords: perf
Whiteboard: c=

Comment 2

6 years ago
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.
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 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.
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: --- → +
(Reporter)

Comment 5

6 years ago
Created attachment 755640 [details]
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
Flags: needinfo?(mvikram)
(Reporter)

Comment 6

6 years ago
Created attachment 755641 [details]
Database for 1 contact

Attached Database for 1 contact
(Reporter)

Comment 7

6 years ago
Created attachment 755643 [details]
Database for 250 contacts

Attached database for 250 contacts
(Reporter)

Comment 8

6 years ago
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.
Status: UNCONFIRMED → NEW
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.
Status: NEW → ASSIGNED
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

Updated

6 years ago
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.

[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.
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 ]

Updated

5 years ago
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]

Updated

5 years ago
Whiteboard: [ c= p=4 s=2013.08.09 ][comms-triaged] → [c= p=4 s= u=1.2] [comms-triaged]

Updated

5 years ago
blocking-b2g: koi? → koi+
Priority: P2 → P1
Whiteboard: [c= p=4 s= u=1.2] [comms-triaged] → [c= p=4 s= u=1.2]
(Assignee)

Updated

5 years ago
Depends on: 905771
Assignee: bkelly → kgrandon
(Assignee)

Updated

5 years ago
Depends on: 907907
(Assignee)

Updated

5 years ago
Duplicate of this bug: 769037
(Assignee)

Updated

5 years ago
Depends on: 909935
(Assignee)

Updated

5 years ago
Blocks: 913775
(Assignee)

Updated

5 years ago
Depends on: 919591
(Assignee)

Comment 17

5 years ago
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
status-b2g-v1.2: --- → fixed
You need to log in before you can comment on or make changes to this bug.