IndexedDB - Performance Comparisons: Part 2

In my previous post, I had written about some comparisons of various IndexedDB operations. Here is a compile of most common cases. Note that there are comments on each test case, and you can look at a test case and leave your thoughts (and interesting discoveries) right on that page.

Comparing keys is pretty much comparing different objects - numbers being the fastest and nested arrays being the slowest. [link]

Interestingly
in Firefox, specifying a version in indexedDB.open() is faster than not
specifying a version. I guess they look up the database meta-data when
it is not specified. [link]

The
presence (or absence) or keypath and auto-increment does not change the
speed on add operation. This is interesting as I always thought that
auto-inrement, or keypath would slow down the opreations as additional
computation would be required. [link]

Adding
more stores to a transaction scope does slow down read operations.
However, since reads do not block each other, should adding more stores
into a read transaction really matter ? [link]

Adding
more stores to a write transaction does slow it down. However, in case
of firefox, all writes in one tranasction is actually faster !! [link]

In chrome, calling put is always faster than calling Add. On other browsers, Add is faster !! [link] No idea why.

Grouping
all read operations in a single transaction is faster than having
multiple transaction. However in IE, grouping transaction is definitely
faster - is this not supposed to be the general case given that read
transactions are non-blocking. [link]

However, multiple write transactions do slow down things as expected - due to contention issues [link]

When
using Cursors, instead of reading or writing in a single cursor,
opening multiple cursors is way faster. Even in case of write, waiting
for a cursor to sequentially write is slower than multiple cursors
waiting and then writing [link]

Adding
Indexes does not seem to slow the read. What about multi-entry indexes
where you would have to fill the index table - should that not be slower
? [link]

Iterating using the cursors on primary key, or an indexes almost equally fast. [link]

Getting just the keyCursor on index is faster that getting the entire objectCursor. [link]