On Sun, Feb 1, 2015, at 11:13 PM, Jonas Sicking wrote: > On Sun, Feb 1, 2015 at 3:28 AM, Kyle Huey <m...@kylehuey.com> wrote: > > Do we have actual evidence that indexeddb performance is a problem? I've > > never seen any. > > Yup. I think this is a very good question. > > Did the people writing > https://wiki.mozilla.org/Performance/Avoid_SQLite_In_Your_Next_Firefox_Feature > gather any data to substantiate the complaints about IndexedDB? Or is > the performance problems inherent due to using SQLite? If so, it would > be good to understand why.
It looks like Vladan wrote the original draft of the page that included the only comment on IndexedDB in there, "IndexedDB is implemented on top of SQLite and has additional issues" (https://wiki.mozilla.org/index.php?title=Performance/Avoid_SQLite_In_Your_Next_Firefox_Feature&oldid=953848), so he can probably speak better, but there is a known current schema deficiency that the awesome :bent is planning to address (as I understand it). IndexedDB's lexicographically ordered keys potentially provide for locality benefits of keys/values located close-together in lexicographic key space. However, older versions of SQLite only supported ordering tables by numeric rowids (which could be a user-provided integer primary key.) This meant that btree locality for small keys/values is/was time-of-insert-based rather than lexicographic-key-based. SQLite has sinced added support for ordering table btrees by any type of primary key you want with the WITHOUT ROWID feature (http://www.sqlite.org/withoutrowid.html). This will allow the IndexedDB schema to be overhauled and potentially significant benefits to be gained for small keys/values. (Pages in the database are expected to be randomly scattered, so spinning media does not particularly benefit when each key is as big as a page. Similarly, SSD's only care about page size, so if your row is as big as the page, there is no wasted I/O that could have been more efficiently utilized.) Another potential benefit log-structured-merge databases like LevelDB can take advantage of is being able to compress keys/values lexicographically close together based on the contents of their neighbors whereas our current IndexedDB can only compress for patterns within a value. But I think SQLite3 has this covered with things like ZipVFS (http://www.sqlite.org/zipvfs/doc/trunk/www/howitworks.wiki). Andrew PS: I understand :bent has other significant cleanups/performance improvements under way as well. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
