Daniel Lemire
Daniel Lemire
In the Go version of RoaringBitmap, @Oppen [contributed some optimizations to the AddOffset functions](https://github.com/RoaringBitmap/roaring/pull/343) which should be applicable to Java as well.
See blog post [Faster sorted array unions by reducing branches](https://lemire.me/blog/2021/07/14/faster-sorted-array-unions-by-reducing-branches/)
We are about to merge this API breaking changes to https://github.com/RoaringBitmap/RoaringBitmap/tree/1.0-SNAPSHOT It has been proposed in https://github.com/RoaringBitmap/RoaringBitmap/pull/461 that we rename the package. I do not mind jumping directly to v2,...
As remarked by @richardstartin and @blacelle, users should not rely on iterable and should favour IntConsumer or something of the sort (for performance).
RoaringBitmap is a stable and well tested library used in major systems (without fault). It is mature, deployed in large commercial setups. However, recently, @incaseoftrouble brought to light some bugs...
Currently Roaring is serialized so as to support memory-file mapping. The net result is that the file format is not as compressed as it could be. We could introduce an...
In some cases, we should be able to greatly improve the performance of array-array intersections. See [Faster intersections between sorted arrays with shotgun](https://lemire.me/blog/2019/01/16/faster-intersections-between-sorted-arrays-with-shotgun/).
Currently, we have forward and backward iterators. For CRoaring, @Brian-Esch implemented bidirectional iterators: https://github.com/RoaringBitmap/CRoaring/pull/190
In many instances, especially when computing intersections, we generate empty containers that are immediately garbage collected. There are clever tricks we could use to start scanning the input containers, advance...