-
Notifications
You must be signed in to change notification settings - Fork 241
Support 1.23 iterator in a backward-compatible way #475
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
Conversation
Can you add benchmarks ? See Line 18 in fb67118
|
@amikai Can you share your benchmark results ? E.g., on your own machine ? |
|
||
t.Run("#6", func(t *testing.T) { | ||
b := New() | ||
b.AddInt(MaxUint32) |
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.
An int might be a signed 32-bit integer, so MaxUint32 can't be represented.
But when it works, you might be allocating 512 MB of memory. Please don't do this as part of our routine tests.
iter_test.go
Outdated
|
||
func TestBackward(t *testing.T) { | ||
t.Run("#1", func(t *testing.T) { | ||
values := []uint32{0, 2, 15, 16, 31, 32, 33, 9999, MaxUint16, MaxUint32} |
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.
This will allocate hundreds of megabytes. Please don't do this in tests.
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.
In fact, I just wrote a similar test of the TestReverseIterator
to make sure the behavior is same as before. How about I change it to values := []uint32{0, 2, 15, 16, 31, 32, 33, 9999, MaxUint16}
? Is that okay with you?
Lines 2428 to 2449 in b705c37
t.Run("#1", func(t *testing.T) { | |
values := []uint32{0, 2, 15, 16, 31, 32, 33, 9999, MaxUint16, MaxUint32} | |
bm := New() | |
for n := 0; n < len(values); n++ { | |
bm.Add(values[n]) | |
} | |
i := bm.ReverseIterator() | |
n := len(values) - 1 | |
for i.HasNext() { | |
assert.EqualValues(t, i.Next(), values[n]) | |
n-- | |
} | |
// HasNext() was terminating early - add test | |
i = bm.ReverseIterator() | |
n = len(values) - 1 | |
for ; n >= 0; n-- { | |
assert.EqualValues(t, i.Next(), values[n]) | |
assert.False(t, n > 0 && !i.HasNext()) | |
} | |
}) |
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.
Good.
iter_test.go
Outdated
|
||
t.Run("#6", func(t *testing.T) { | ||
b := New() | ||
b.AddInt(MaxUint32) |
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.
This will allocate hundreds of megabytes. Please don't do this in tests.
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.
Same as before, I just wrote a similar test to make sure the behavior same as before. Will delete this test.
Lines 2488 to 2496 in b705c37
t.Run("#6", func(t *testing.T) { | |
bm := New() | |
bm.Add(MaxUint32) | |
i := bm.ReverseIterator() | |
assert.True(t, i.HasNext()) | |
assert.EqualValues(t, uint32(MaxUint32), i.Next()) | |
assert.False(t, i.HasNext()) | |
}) |
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.
@amikai It is entirely possible that it was pre-existing. it is still a terrible idea. :-)
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.
To be clear, we do not have AddInt(MaxUint32)
in the code base because that does not work....
MaxUint32
may not fit in an int
.
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.
Sorry, I didn't see clearly.
Hi @lemire, here is the benchmark on my computer:
|
@amikai The performance is ok. Can you just tweak the small things I flagged ? We will be able to merge. |
Hi @lemire, I have tweaked the test. |
Great. I am running the CI tests, if it passes, we shall merge and release !!! |
Hi @lemire, If there any concerns to merge the PR and release? |
Merging! |
This builds on the previous work in RoaringBitmap#475.
Resolve #471
Provide two new functions:
Values
: An iterator in normal orderBackward
: An iterator in reverse orderUnit test:
iter123_test.go
: Test the 1.23 iterator by for-rangeiter_test.go
: Test the iterator by call function wayDesign consideration
slices.Values
andslices.Backward
to make it easier to use.Values
andBackward
before version 1.23 without for-range function syntax, which means we don't need to update the go.mod version.iter
package.Hi @lemire,
The unit test I wrote uses a similar approach to the one for testing
Bitmap.ReverseIterator
andBitmap.Iterator
. However, I am not confident that the test case is robust enough. Could you please review it? If you find the implementation acceptable, I will proceed with writing the Go doc comments and add examples to it.