-
Notifications
You must be signed in to change notification settings - Fork 103
feat/perf: optimize AddRange in RoaringPositionBitmap #608
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 2 commits
acc264b
520a868
1f70485
3c4ce82
45ee748
571c076
ab7e189
7214fa1
3c55027
6f7a1db
9c06f42
44df040
4421d7d
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -65,6 +65,7 @@ class ICEBERG_EXPORT RoaringPositionBitmap { | |
| void Add(int64_t pos); | ||
|
|
||
| /// \brief Sets a range of positions [pos_start, pos_end). | ||
| /// If pos_start >= pos_end, this method does nothing. | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This contradicts the note sentence below. |
||
| /// \note Invalid positions are silently ignored | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. rephrase may be state pos_start >= pos_end is considered invalid.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I have made it invalid if pos_start > pos_end, technically I can imagine cases where pos_start == pos_end, therefore i keep that as a no-op. Let me know what you think. |
||
| void AddRange(int64_t pos_start, int64_t pos_end); | ||
|
|
||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
its not clear to me this is correct, don't we need to fill in valid values?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1
We need to ignore invalid positions but set values for valid ones.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, i follow the style of the normal operation, to ignore invalid positions, and clamp inputs to correct values.
However, this is inconsistent with the behaviour of core Java, where positions gets validated, and errors out if they are out of range.