Optimize bitmap container batch iteration

[perfloop-agent]

Description

Optimize bitmap-container batch decoding for ManyIterator and ToArray.

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Performance improvement
• Code refactoring
• Documentation update
• Test improvements
• Build/CI changes

Changes Made

What was changed?

• Replaced popcount-based bit extraction in bitmapContainerManyIterator.nextMany and nextMany64 with bits.TrailingZeros64 and lowest-set-bit clearing.
• Added benchmarks for public 64-bit ToArray and ManyIterator decoding paths.

Why was it changed?

• Batch decoding did extra work to locate each set bit and rechecked output capacity for every value.

How was it changed?

• A bitmap word is drained through a tight loop when at least 64 output slots remain. Partial buffers keep the bounded path.

Testing

• go test -v
• go test -v ./roaring64
• go test -v ./BitSliceIndexing
• go tool unconvert ./...

Checks: 4 passed.

Formatting

• Ran gofmt on the changed Go files.

Fuzzing

• Not run; the change is confined to in-memory bitmap iteration.

Performance Impact

• The benchmarks decode 32,768 values from one bitmap container and verify the returned values.
• The fast path is used only with at least 64 remaining output slots; partial buffers retain the bounded path.

Workload: roaring64ToArray

Metric	Before	After	Change
ns/op	92718	61471	33.7% lower

Workload: roaring64ManyIterator

Metric	Before	After	Change
ns/op	60844	31408	48.4% lower

Breaking Changes

• None.

Related Issues

• None.

Additional Notes

• No API changes.

---

Generated by Perfloop. Measurements and checks.