IndexedDB Object Keys: Does Size Matter?

Question

I am going to store many objects in the indexeddb object store. All objects have the same structure, something like {somekey: xxx, somevalue: yyy} .

Does the length of the keys of object objects increase the size of the stored data? For example, if I changed the structure to {s: xxxx, v: yyyy} , should I expect that the object store will have a better place with current browsers?

I could not find any information about this anywhere in the standard, so I assume that before implementing browsers for internal use of the dictionary or not, and I would like to know how it is currently running, and this is a worthy optimization to reduce the size keys of storage objects.

Answer 1

Yes, it will affect it. But at least for keys with a reasonable size, one character versus 10 or 20 characters will not make any difference in performance if you are not on a very large scale (millions of records). Most implementations (including chrome, for which I can speak) store the complete object, including key names, but indexes only save the "key path" once ..

Assuming that {"foo": "bar"} probably takes about ~ 12 bytes to store (approximately 4 bytes for each line, plus some overhead like, but the subsequent index on "foo" will only store "Baz".

{"foobarbaz": "helloworld"} probably takes ~ 23 bytes to store. Indeed, I would expect that in most cases your own data should outshine the overhead by the length of the key, and trying to shorten your keys to save a few bytes is a premature optimization.