[Contacts] [Data Refactor] Compare performance between indexedDB-based suffix array and in-memory-based

ASSIGNED

Status

Firefox OS
Gaia::Contacts
P3
normal
ASSIGNED
3 years ago
3 years ago

People

(Reporter: Jose Manuel Cantera, Assigned: Jose Manuel Cantera)

Tracking

(Blocks: 1 bug, {perf})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [c=progress p= s= u=])

Comment hidden (empty)
(Assignee)

Comment 1

3 years ago
The branch used can be found at:

https://github.com/jmcanterafonseca/gaia/tree/contact_indexing_suffix_array

The application used is 'ContactsManager'. First it is needed to load and index a set of 500 contacts. That process can take time. Automatically it will be generated 2 indexes:

* a regular suffix array, based in memory. That index can be persisted to a datastore and to a JSON object stored on the SDCard. ('Persist' button) 
* a indexedDB based suffix array 

Findings: 

The indexedDB search is around 10-15 times slower than the in-memory search. In-memory search is taking around tens of milisecs to resolve a search query whereareas indexedDB one is taking hundreds of milisecs. 

The indexedDB-based index is occupying > 4 Mb in disk. Further optimizations might be done. 
Once the in-memory based index is loaded, the RSS of the app augments in around 15Mb. 

The search can be done using both indexes. For certain queries the results can be a bit different as the searching algorithms vary and we are setting a limit for the first 10 results.
See Also: → bug 1031318
(Assignee)

Updated

3 years ago
Assignee: nobody → jmcf
Status: NEW → ASSIGNED
Keywords: perf
Whiteboard: [c=progress p= s= u=]

Updated

3 years ago
Priority: -- → P3
(Assignee)

Comment 2

3 years ago
Latest update:

The above branch includes an experimental hybrid solution which allow us to use the best of both worlds:

https://github.com/jmcanterafonseca/gaia/tree/contacts_search_improved

SuffixArray supported by indexedDB. Using this approach we have two advantages:

1/ For 2000 Contacts the indexedDB is only occupying around 4 Mbs
2/ The RSS of the app does not raise so much as we only load in memory the corresponding chunk (based on the start letter) of the suffixArray 

I believe search times can be improved but that can be done in another iteration.
Blocks: 854826
You need to log in before you can comment on or make changes to this bug.