Daniel Lemire

If you look at a typical execution of `roaring64_iterator_advance`, it almost always call directly `container_iterator_next`. So we have a cheap function calling another cheap function. This makes is a good...

PR https://github.com/RoaringBitmap/CRoaring/pull/766 should help. Basically, I am moving to make more code inlineable.

@RinChanNOWWW I am not 100% convinced about your motivation. We already support conversion to a bitset: ```c roaring_bitmap_t *r1 = roaring_bitmap_create(); for (uint32_t i = 100; i < 100000; i+=...

@RinChanNOWWW That's an excellent answer, but I am not sure what you have implemented would work for ClickHouse. Look at the use case: ```c roaring::api::roaring_uint32_iterator_t it; roaring_iterator_init(data.bitmap32, &it); if (!roaring_uint32_iterator_move_equalorlarger(&it,...

@RinChanNOWWW I understand, but I am concerned about adding functions for which I see no obvious use. Your analysis is excellent, but it suggests that the range functions are what...

My concern at this point is the user of the iterator in the function signatures. It seems to me that it makes the code unnecessarily complicated.

> I write a benchmark and find that the performance is already better than iterating by uint32 iterator. Yes. I am not concerned with the efficiency of your implementation. Your...

@RinChanNOWWW My recommendation at this stage is that we tune the change in CRoaring to what is useful to ClickHouse's design. It would be a shame to add a specialized...

I am going to run tests. When you are ready to issue a ClickHouse pull request, we can prepare a tentative release, and see how it works out.

This is great, brilliant even ! Yes, having distinct implementations is not great (makes testing more difficult and so forth). > Also, I do not know how much changes are...