[Webkit-unassigned] [Bug 164754] New: IndexedDB 2.0: Key collation during SQLite lookups is insanely slow

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=164754

            Bug ID: 164754
           Summary: IndexedDB 2.0: Key collation during SQLite lookups is
                    insanely slow
    Classification: Unclassified
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebCore Misc.
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: beidson at apple.com

IndexedDB 2.0: Key collation during SQLite lookups is insanely slow

This is what causes us to fail imported/w3c/web-platform-tests/IndexedDB/idbindex-multientry-big.htm due to timing out.

Looking at profiles one can confirm that a vast majority of the time is spent under WebCore::idbKeyCollate, and most of that time is spent allocating, using, and deallocating both Strings and CFPropertyLists.

Using KeyedEncoder/Decoder for IDBKeys on disk was probably a bad idea; Common keys (e.g. a number) are *MUCH* larger than they need to be, and all keys require a lot of memory churn and CPU time just for SQLite's comparison sake.

If we move to a custom serialization format targeted at IDBKeys we can vastly improve this.

That last statement is not a hypothesis; The afore mentioned idbindex-multientry-big.htm takes ~26 seconds to complete with timeouts disabled today, but with a custom format it takes less than 2 seconds.
And profiling confirms that whereas collation is ~97% of the 26 seconds, it is less than 1.4% of the ~2 seconds.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20161115/038493e8/attachment-0001.html>