Contacts API: mozContacts.getAll() seems slow

NEW
Unassigned

Status

()

Core
DOM: Contacts
P5
normal
5 years ago
19 days ago

People

(Reporter: bkelly, Unassigned)

Tracking

(Depends on: 3 bugs, {perf})

unspecified
ARM
Gonk (Firefox OS)
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(tracking-b2g:backlog)

Details

(Whiteboard: [c= p=5 s= u=][sprd314613])

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
Currently mozContacts.getAll() seems abnormally slow.  In a stripped down app that does nothing but call getAll() with no sorting or filtering options, it takes ~3.5 seconds to load 1000 contacts on my Buri.

While I know that a lot of good work has already gone into optimizing Contacts API, I can't help feeling that things are still unusually slow.

In an attempt to quantify this feeling I thought perhaps we could look at it in terms of bandwidth.  If we call JSON.stringify().length on the 1000 contacts in reference-workload-heavy, we can approximate the amount information to be accessed at 645,628 bytes.  This means we are accessing contact data at about 1.4Mbit/s from the app.

For comparison:

  mozContacts.getAll():    1.4   Mbit/s
  802.11b:                 11    Mbit/s
  File system:             50    Mbit/s
  Memory copy:             650   Mbit/s

(The file system was estimated using dd on a cold cache right after device boot.  Memory bandwidth was estimated from dd on a hot cache.)

I understand this comparison is a bit unfair since contacts has to provide more functionality than simple data access, but I just wanted to show the differences for some rough perspective.

Considering that all of the contacts data is local to the device, the current mozContacts.getAll() numbers look a bit out of whack to me.  They might seem reasonable if we were running over the network, but we're not.

This was all on a Buri using mozilla-central at 134166:12cdc8931e48.

In any case, I was not aware of a top level bug discussing this so I thought I would write my thoughts up.  I hope this bug is not too controversial.  From discussing the topic with various people it seems like its a known issue that we would like to address.  It just seemed that it might be helpful to separate it out into its own bug.
(Reporter)

Comment 1

5 years ago
Created attachment 769421 [details]
Link to simple app used to measure contacts API.

The code for the simple test app I used to measure the contacts API on its own can be found here:

  https://github.com/wanderview/gaia/tree/contacts-api-bench/test_apps/contacts-bench
Attachment #769421 - Attachment mime type: text/plain → text/html
Just making a note that we should never ever use, or encourage people to use, getAll for the contacts API. Perhaps some performance investigation wouldn't hurt if we could speed up cursor methods though :)
(Reporter)

Comment 3

5 years ago
(In reply to Kevin Grandon :kgrandon from comment #2)
> Just making a note that we should never ever use, or encourage people to
> use, getAll for the contacts API. Perhaps some performance investigation
> wouldn't hurt if we could speed up cursor methods though :)

mozContacts.getAll() does return a cursor.  Are you thinking of IDB's mozGetAll()?
Ah right, I must be - ignore me. Sorry for the comment spam!

Updated

5 years ago
OS: Mac OS X → Gonk (Firefox OS)
Hardware: x86 → ARM
Whiteboard: [c= ]
(Reporter)

Updated

5 years ago
Blocks: 865747
(Reporter)

Comment 5

5 years ago
One current working theory is that the locale based sorting outside of IDB is contributing to the slowdown.  To fix that, however, we would need bug 871846.
Depends on: 871846
(Reporter)

Comment 6

5 years ago
Bug 872741 would also help with these load times as it helps optimize the loading of the sort cache.
Depends on: 872741
(Reporter)

Comment 7

5 years ago
Bug 873873 shows that IPC costs from parent to child process is a non-trivial part of the picture.
Depends on: 873873
Depends on: 888801
(Reporter)

Comment 8

5 years ago
I re-ran the benchmark with a recent m-c today:

  Rev:      139136:4eeefa65fffa
  Results:  3459ms, 3513ms, 3502ms, 3603ms, 3477ms
  Content:  1000 contacts (reference-workload-heavy)
(Reporter)

Comment 9

5 years ago
I rebased my contacts API bench app here today:

  https://github.com/wanderview/gaia/tree/contacts-api-bench/test_apps/contacts-bench

And re-ran the benchmark again m-c:

  Rev:      150676:3a486112072b
  Results:  3900ms, 3913ms, 3915ms
  Content:  1000 contacts (reference-workload-heavy)

It seems we have regressed about 10%.
(Reporter)

Comment 10

5 years ago
Gregor, any idea what could have caused mozContacts.getAll() to regress by about 10%?  Unfortunately I have quite a wide starting range between comment 8 and comment 9.
Flags: needinfo?(anygregor)
(Reporter)

Comment 11

5 years ago
Note, I did change the contacts bench app to wait 15 seconds instead of 5 seconds before starting the test.  I wanted to make sure there was no conflict with the pre-allocated process launch (which occurs on a 5 second delay).
(Reporter)

Updated

5 years ago
Depends on: 926752
(Reporter)

Updated

5 years ago
Depends on: 927028
(Reporter)

Comment 12

5 years ago
I opened bug 927028 track the regression from comment 9.
Flags: needinfo?(anygregor)

Updated

5 years ago
Component: DOM: Device Interfaces → DOM: Contacts
(Reporter)

Updated

5 years ago
Depends on: 931164
(Reporter)

Comment 13

5 years ago
We have regressed further due to the webidl change.  See bug 931164.  Recent numbers:

  152235:2f2a45f04e7c + workaround patch from bug 929652:  4056ms, 4014ms, 4061ms
(Reporter)

Updated

5 years ago
Status: NEW → ASSIGNED
QA Contact: bkelly
(Reporter)

Updated

5 years ago
Whiteboard: [c= ] → [c= p=5]
(Reporter)

Updated

5 years ago
Assignee: nobody → bkelly
QA Contact: bkelly
(Reporter)

Comment 14

5 years ago
Speculatively setting a dependency on bug 768074 since it seems probably it could help here.

Also, dropping this from my current queue as I need to focus on 1.2 bugs.
Assignee: bkelly → nobody
Depends on: 768074
(Reporter)

Updated

5 years ago
Status: ASSIGNED → NEW
(Reporter)

Updated

4 years ago
Priority: -- → P3
Whiteboard: [c= p=5] → [c= p=5 s= u=]

Updated

4 years ago
blocking-b2g: --- → 1.3T?
Whiteboard: [c= p=5 s= u=] → [c= p=5 s= u=][sprd314613]
Can we improve this API performance for tarako only?
Flags: needinfo?(styang)
Flags: needinfo?(fabrice)
(In reply to James Zhang from comment #15)
> Can we improve this API performance for tarako only?

What do you want to improve? Whats the STR thats slow? Is it the first contact returned, the time to fetch all contacts? And whats the workload?
perf improvement. let's not block on this for tarako release unless it is extremely slow
blocking-b2g: 1.3T? → backlog

Updated

4 years ago
Flags: needinfo?(styang)
Flags: needinfo?(fabrice)
(Assignee)

Updated

3 years ago
blocking-b2g: backlog → ---
tracking-b2g: --- → backlog
Bulk priority change, per :mdaly
Priority: P3 → P5
You need to log in before you can comment on or make changes to this bug.