RoaringBitmap v2.21.0 - Faster Bitmap Container Materialization

RoaringBitmap published v2.21.0 on July 13, 2026. The release changes one focused CPU path: bitmapContainer.fillLeastSignificant16bits now extracts set bit positions with math/bits.TrailingZeros64 during dense bitmap array materialization.

The full release notes and downloads are on the GitHub release page.

The release replaces the previous loop inside bitmapContainer.fillLeastSignificant16bits. That loop isolated the lowest set bit, then used population counting and extra bit operations to derive its position. The new loop calls math/bits.TrailingZeros64 to obtain the position directly and clears the processed bit with bitset &= bitset - 1.

This is a narrow change in bitmapcontainer.go, not a new bitmap format or public operation. Its target is the conversion of a dense bitmap container into an array of 16 bit values. Each set bit passes through the loop, so removing repeated scalar work matters most when a container has enough values to make that loop hot.

On amd64, the compiler can lower the new pattern to TZCNT and BLSR. The pull request deliberately limits that instruction claim to this architecture. Operators should not project the same result onto every CPU target without running the included benchmark on their own build hosts.

The exact implementation and review context are in pull request 534.

The added BenchmarkBitmapContainerFillLeastSignificant16bits measured the changed function on Linux, amd64, and Go 1.26.4. Across ten benchmark runs, reported time fell from 41864.5 ns/op to 29265 ns/op, or about 30.1%. Memory stayed at 0 B/op and 0 allocs/op.

The pull request supplies a repeatable command: go test -bench='^BenchmarkBitmapContainerFillLeastSignificant16bits$' -run='^$' -count=10 -benchmem .. Run it with a fixed Go version and compare results per architecture rather than across mixed runners.

Those numbers describe this container materialization benchmark. They do not establish a 30 percent improvement for an index, ETL job, query service, or complete data pipeline. End to end impact depends on how much CPU time a workload spends materializing dense bitmap containers. Pipelines that mainly perform bitmap intersections, serialize containers, or process sparse data may see little movement.

For operators, the useful signal is more specific. The patch reduces instructions in a known loop without trading CPU time for heap activity. That makes it a reasonable update to test where profiles already show array materialization as a measurable consumer.

The change also adds TestBitmapContainerFillLeastSignificant16bitsProperties in bitmapcontainer_test.go. The differential property test covers random dense and sparse cases across the full 16 bit container range. It checks boundaries, generated values, and return values against the previous behavior.

Existing correctness tests passed alongside the new property coverage. The pull request also records successful formatting and static analysis checks. These additions matter because bit extraction optimizations are compact code with a wide correctness surface: a mistake in one offset or boundary can silently corrupt the materialized value list.

There are no documented API changes, behavior changes, migration steps, or breaking changes in v2.21.0. No configuration keys or data formats need conversion. The practical upgrade check is performance validation on the architectures and workload shapes used in production, with existing bitmap correctness tests left in place.