Regarding memory use of maximum size and removal of bit number about roaring

[lemire]

i'll be using the 64bit version

The storage bound is for 32-bit roaring bitmaps. It is provided as a mathematical formula in the README and we have an actual function in the software. Both are precise, not vague.

We don't have bounds for the 64-bit version. It is a separate implementation. If you'd like to contribute a computed bound for the 64-bit version, a pull request is invited.

if i remove a bit (whatever position) from the roaring bitmap, does that mean the memory is cleared / shrink too?

We don't store individual bits/elements. The format is adaptative, with a container type model. We follow the roaring format specification: https://github.com/RoaringBitmap/RoaringFormatSpec

You may want to read the related research papers such as...

• Daniel Lemire, Gregory Ssi-Yan-Kai, Owen Kaser, Consistently faster and smaller compressed bitmaps with Roaring, Software: Practice and Experience 46 (11), 2016. arXiv:1603.06549

any suggestions on how to convert a key to 64bit or 32bit roaring bitmap for use an a cache? is this advisable?
e.g. blake3.Sum32("key")

Please consult the README where we try to answer the general question as to when a compressed bitmap is appropriate https://github.com/RoaringBitmap/roaring#when-should-you-use-compressed-bitmaps

It looks to me like you might be in need of a Bloom filter (for example): https://github.com/bits-and-blooms/bloom

[lemire]

I am closing. This is not a valid issue. The reporter is invited to do some research, benchmarking, and so forth.