1031306 - [Contacts][Data Refactor][Meta] Contacts storage investigations

Status: RESOLVED FIXED

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

Description

[Francisco Jordano [:arcturus] [:francisco]]

With the contacts data refactor we plan to solve three different problems:

- Make easier and simplier to integrate any contacts source
- Make the contacts list super fast
- Make the search experience better, not relaying on DOM

For that we will be using Datastores as a key component in our architecture for share data between applications, but contacts app needs something that is searchable, and information can be processed to specific needs of contacts app (without having to ask mozContacts API for more stuff).

This meta bug will track some ideas that we want to test to validate what's the best way to proceed.

Comment 1

[Francisco Jordano [:arcturus] [:francisco]]

We have been discussing two possible approaches:

- We keep copies of merged contacts to deal with them as we have right now with mozContacts API.
- We go aggressive and don't store anything, just the fields needed for presenting the list (+ search)

We will be doing some experiments to decide about what's the best option.

Comment 2

[Francisco Jordano [:arcturus] [:francisco]]

We landed bug 989929, that currently goes for first solution,  but after discussions we came with this metabug to explore the best solution.

Comment 3

[Francisco Jordano [:arcturus] [:francisco]]

Here is a resume of what we discovered with the previous experiments:


Bug 1031315 - [Contacts][Data Refactor]Check performance of building contact details from different DS

- DB with 500 contacts
- Time to contacts directly from a indexedDB or indexedDB + DS -> 4 times slower when composing. indexeddb 30-40 ms vs composing 150 ms
- As an intermediary solution, we can cache the full details of the contacts that we see. Having just a subset of the contacts.
- In case of the thumbnail, as they could be big when we have 2000 contacts, the GCDS can offer them (in a different store).


Bug 1031318 - [Contacts][Data Refactor] Better search in contacts

- All in memory: 1MB with 2000 contacts
- Indexeddb: Problems with traversing

Going for indexedDB, try to use the concept of suffix array, the problem is the memory


Bug 1031324 - [Contacts][Data Refactor] Check impact of copying full contacts information in indexDB

- See the rest


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

- 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

We should save a minimun for display the contacts list.



Other findings:
- Specific datastore for contacts matching information