You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the size of an entry is abused to indicate that it was deleted (the size is negated)
It would be better to have a user metadata thing for this instead.. maybe two or even 4 bytes per entry?
Another idea: the ofst file only contains increasing uint's and so could be a roaring bitmap, too.
I tested this on an go-ssb log with nearly a million entries. It decreased the size of the file from 9mb to 1.7mb. It would mean that all the entries have to fit into uint32, though, which means the last feasable entry would be around math.MaxUint32.
The text was updated successfully, but these errors were encountered:
Currently, the size of an entry is abused to indicate that it was deleted (the size is negated)
It would be better to have a user metadata thing for this instead.. maybe two or even 4 bytes per entry?
Another idea: the ofst file only contains increasing uint's and so could be a roaring bitmap, too.
I tested this on an go-ssb log with nearly a million entries. It decreased the size of the file from 9mb to 1.7mb. It would mean that all the entries have to fit into uint32, though, which means the last feasable entry would be around math.MaxUint32.
The text was updated successfully, but these errors were encountered: