[K/N] Make the full build of a CustomBitSet lazy

[troelsbjerre]

This changes the representation of CustomBitSet to initially be an explicit list of set bits, until the cardinality grows beyond a fixed size. This saves a lot of memory, since many of the use cases of CustomBitSet are sparse.

[kotlin-safe-merge]

Code Owners

Rule	Owners	Approval
/​kotlin-​native/​	kotlin-native	🔴

[anton-bannykh]

I observe a roughly 25% speedup on a reasonably large KMP project. Good job! 🎉

[anton-bannykh]

So far the biggest question I have is how clearing a bi should be handled. When the bits are only added everything is clear, and there are some nice invariants we could rely on. When a bit is cleared then suddenly we can get same bitsets with different internal representations. That complicated stuff quite a bit.

What do you think? Did not convert a bitset back to the lazy for as shrinks intentionally?

[troelsbjerre]

I don't think the efficiency loss of enforcing an invariant like "for cardinality < k, it's always an IntArraySet, and otherwise a BitSet" would be worth it. Tracking cardinality of the BitSet would complicate the implementation, and switching back and forth between representations would be potentially costly, where "add(1); remove(1); add(1);..." would potentially require allocating a huge LongArray on every add.

[anton-bannykh]

Probably fine to use, will double check

[troelsbjerre]

It's worth noting that the fastutils library is used elsewhere in the compiler. This is not a new dependecy.

[anton-bannykh]

[major] When using the private contructor the lazy property still gets initialized. This leads to effective "empty" lazy bitset despite the data array that was passed.

This affects the copy method and the valueOf companion method

[mcpiroman]

You may also be interested in using a library such as https://github.com/RoaringBitmap/RoaringBitmap. As I get it, it implements an optimized bitmap with a dynamic underlying representation, similar to the one proposed here.

[anton-bannykh]

You may also be interested in using a library such as https://github.com/RoaringBitmap/RoaringBitmap. As I get it, it implements an optimized bitmap with a dynamic underlying representation, similar to the one proposed here.

I tried it back in August, didn't observe any benefit for some reason 🤷 . Maybe I used it wrong or something.

[troelsbjerre]

You may also be interested in using a library such as https://github.com/RoaringBitmap/RoaringBitmap. As I get it, it implements an optimized bitmap with a dynamic underlying representation, similar to the one proposed here.

I'll do a quick test to see if there is a noticeable difference. I suspect the general RoaringBitMap might be at a disadvantage for the common case of very sparse BitSets, with only a handful of set bits.

[troelsbjerre]

Changing from CustomBitSet to RoaringBitmaps, the peak memory usage drops by 5%, but the link step takes 11% longer.