Closed
Bug 1031327
Opened 11 years ago
Closed 11 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)
Firefox OS Graveyard
Gaia::Contacts
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.
Assignee | ||
Updated•11 years ago
|
Assignee | ||
Updated•11 years ago
|
Assignee: nobody → francisco
Assignee | ||
Updated•11 years ago
|
Whiteboard: [p=4]
Target Milestone: --- → 2.0 S6 (18july)
Assignee | ||
Comment 1•11 years ago
|
||
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: 11 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•