As part of data refactor we want to avoid doing search based on DOM. Right now we need the whole dome to be build in order to search, and also build the search string (normalization of fields we allow to search) each time we build the list (per item). That makes contact search awnfull, moving to having our own storage (idb), how we can make this search more effective? Can we have something close to full text search? And have this info precalculated. We need to find the best way to organize internal data for contacts to do an effective search.
Assignee: nobody → sergi.mansilla
Conclusions: All in memory: Full-text search, extremely fast on any field (1-2ms), but 1MB memory with 2000 contacts Indexeddb: Slow traversing, we need 8 seconds to do this. We will probably go with indexeddb since the memory consumption is too high, also we need to check concepts like suffix array to see if we can apply them to indexeddb, but it looks that traversing the indexes will have a speed penalty. Still, better than high memory usage.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Tests can be found here: https://github.com/sergi/idb-benchmarks
You need to log in before you can comment on or make changes to this bug.