Closed Bug 1031327 Opened 10 years ago Closed 10 years ago

[Contacts][Data Refactor] Measure time to finish cursor when information stored is a full mozContact or just the bare minimun information

Categories

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

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
2.0 S6 (18july)

People

(Reporter: arcturus, Assigned: arcturus)

References

Details

(Whiteboard: [p=4])

We will be using cursors in idb.

We need to measure the time that takes to render a 2000 contacts list using cursors when we fetch a full contact or we store the minimun information to draw a item in the contacts list.

Also we can check with precalculated data, to render without having to calculate in 'gaia' time what we should display. Of course this should be faster, but we need to know what's the winning here.
Blocks: 1031306
No longer blocks: 1031315
Assignee: nobody → francisco
Whiteboard: [p=4]
Target Milestone: --- → 2.0 S6 (18july)
https://github.com/arcturus/contacts-idb-test

Hi folks,

some nice findings, the app you have there does 2 things:
- Get current mozContacts api, and walk a cursor. During this walk we perform all the ops we do right now in the contact list to select the display name, group and so on, and it measures the time consumed until we process the latest contact
- 2nd part just fills a local indexeddb with the data from mozContacts, with the same information that we precalculate, so we don't have to do operations (calculate search string, etc), thats the fill db button, and also walks that indexddb with a cursor.

The results are quite nice, for 2000 contacts we got the following:
- Time to first contact is more or less the same ~ 80-100 ms
- Time to last contact with mozContacts is around 6.6~6.8 seconds
- Time to last contact coocked with indexeddb is around 2.8~3 seconds

Only problem is space, we needed to remove the photo, otherwise we were having 33MB idbx :(, same contacts set without photo es on 1.2MB, indexes were not looking expensive size wise.

So sounds like a good idea to have an object store with precalculated row information for speeding up the contacts performance.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.