Why doesn't storage.sync simply have a maximum total size?

Add-ons Development
#1

I was wondering what the point of limiting both the total size and the number/size of items is? There are use cases where either large strings of values or short but numerous items are useful. And, is there an disincentive, beyond minor performance effects, for nesting objects inside an individual item?

Thanks

#2

This is following Chrome’s design for compatibility, so… maybe they’ve answered that question?

(For reference, also not answers)

#3

Oh okay, thanks!

Looking at their documentation although they don’t explicitly state it, it seems it may have been put into place to limit sustained writes. However, since they have removed their limit, it seems pointless.

#4

I’m pretty sure the reason is pragmatic - if it’s too performance intensive, it’s forbidden.

Chrome synchronizes this storage right right away (within seconds) unlike Firefox that takes minutes. So Chrome added many restrictions so that updates are are always small and cheap. That’s why you have:

MAX_ITEMS = 512;
MAX_WRITE_OPERATIONS_PER_HOUR = 1_800;
MAX_WRITE_OPERATIONS_PER_MINUTE = 120;
QUOTA_BYTES = 102_400;
QUOTA_BYTES_PER_ITEM = 8_192;

But you can write a simple wrapper around your save / load functions that will go around these limitations by splitting big parts into small pieces or by merging multiple small chunks into bigger pieces…

#5

Ah okay, that is what I thought it might be. I saw they had removed “MAX_SUSTAINED_WRITE_OPERATIONS_PER_MINUTE” but did not realize it had been replaced with “MAX_WRITE_OPERATIONS_PER_MINUTE”. That explains the limit to the length of the each item. But, why would there need to be a “MAX_ITEMS” in that case?

#6

The top level items are main “dictionary” so the more keys you have, the more work it brings - and the more memory it consumes as the server needs to load all keys into memory so that it can perform the data merging.

For example, if you add 10 items on one device and 10 on second device at the same time, the server backend will merge them together.
For example:
Device A will store: {a: 1, b: 2}
Device B will store {a: 0, c: 3}

The result should be {a: 0, b: 2, c: 3}.
So imagine merging two 10_000 lists - they would fit into storage, but the merging would be heavy. And you can do it 120 times per minute!