Core: Optimize RoaringPositionBitmap.setRange with native range API#15791
Merged
danielcweeks merged 4 commits intoapache:mainfrom Apr 15, 2026
Merged
Conversation
Replace the O(n) per-position loop in setRange() with native RoaringBitmap.add(long, long) bulk range insertion. The new implementation splits 64-bit ranges at key boundaries and delegates to the native range add API, reducing cost from O(range_size) to O(containers_touched) and eliminating per-position validation and bitmap allocation checks.
…y ranges Add tests that verify every position in a range via contains() for both the same-key and cross-key code paths. Strengthen the empty range test to cover start == end and start > end cases with cardinality and contains() assertions.
… tests Document that setRange does nothing when start >= end. Add assertThatThrownBy tests for setRange with negative start and end beyond MAX_POSITION to match existing set/contains coverage.
This was referenced Mar 29, 2026
Comment on lines
+89
to
+91
| if (posStartInclusive >= posEndExclusive) { | ||
| return; | ||
| } |
Contributor
There was a problem hiding this comment.
I think the original implementation had an unintended side-effect of returning in this case, but we should probably have a precondition check and throw as setting this wrong indicates there's a problem.
Contributor
Author
There was a problem hiding this comment.
Thanks, I changed it to error out instead.
A reversed range (start > end) indicates a bug in the caller and should fail fast rather than silently succeed. An empty range (start == end) remains a valid no-op. This makes setRange consistent with set() which already validates its input via Preconditions.checkArgument.
Contributor
Author
|
Since i was asked for a benchmark. Here is the results, and links to related PRs in the other subpackages: Related PRs:
Benchmark results
|
wgtmac
pushed a commit
to apache/iceberg-cpp
that referenced
this pull request
Apr 4, 2026
Replace the per-position loop in `RoaringPositionBitmap::AddRange` with direct calls to `roaring::Roaring::addRange`, matching the optimization in the Java implementation (apache/iceberg#15791). Added tests for single-position ranges, large contiguous ranges, three-key spanning ranges, and invalid inputs.
danielcweeks
approved these changes
Apr 15, 2026
Contributor
|
Thanks @Baunsgaard! |
Contributor
Author
|
Thanks for reviewing and merging ! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Replace the per-position loop in
RoaringPositionBitmap.setRange()withRoaringBitmap.add(long, long)bulk range insertion.The new implementation splits the 64-bit range at key boundaries and delegates each segment to the native API, which operates at the container level internally. This also eliminates per-position validation and bitmap array growth checks.