roaring-rs
roaring-rs copied to clipboard
Constant time len
Fixes #45 Closes #105
I'm not sure what the right approach to testing this is.
I'm not sure what the right approach to testing this is.
Do you mean benchmarking the constant length or checking that select
which uses len()
is valid?
You already added tests for the select
method so... Nothing more to do.
However, checking that the length is valid is maybe a little bit complex, we could maybe add an iter().count() == .len()
after all of our proptests or something?
However, checking that the length is valid is maybe a little bit complex
This is what I meant. I'm trying to think of a clean way to debug_assert
that each time the len changes we compare it against the computed len
This is what I meant. I'm trying to think of a clean way to
debug_assert
that each time the len changes we compare it against the computed len
Wouldn't it be ok to directly do debug_assert_eq!(self.iter().count(), self.len())
? As the macro expansion is done at compile-time, therefore the call to iter/count is only done for debug builds.
I just hope that we haven't implemented the count
method on our iterator to only call self.len()
😂
I just checked in the playground and the macro expansion indeed works like that: it didn't panic when compiling in release.
I just hope that we haven't implemented the
count
method on our iterator to only callself.len()
Of course it does. Why should it recompute the cached len?
Edit: It's an exact size iterator whose size hint is initialized by RoaringBitmap::len
I believe ExactSizeIterator
overrides count to return the exact size
Of course it does. Why should it recompute the cached len?
Ok so we should trick by doing a fold
instead.
Of course it does. Why should it recompute the cached len?
Ok so we should trick by doing a
fold
instead.
We'd probably have to wrap it in a black_box
. LLVM is very clever.
Thinking we should assert invariants #197 before we merge this to be sure we didn't introduce a regression