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_assertthat 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
countmethod 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
foldinstead.
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