To support that, this patch also does the following.
- Removes the insert(), remove() and might_contain() methods, because they are
specialized versions of insert_hash(), remove_hash(), and
might_contain_hash(), and they are only used by tests within this file.
- Moves hash() from the top level into create_and_insert_some_stuff().
- Changes create_and_insert_some_stuff() so that instead of hashing consecutive
integers, it instead hashes stringified consecutive integers, which matches
real usage a little better.
- Raises the false_positives limit a little to account for the above changes.
Bug: 1484096
Reviewed-by: heycam
It seems that the result of hash algorithm used in bloom filter depends
on the pointer length. On 64bit platforms, there are 135 false positives
in the first part of that test, and 8 in the second part. However, on
32bit platforms, the numbers become 157 and 16 correspondingly.
16 is still less than 20% in the second part, so all fine, but 157 is
slightly larger than 15% in the test assertion. Given it is what we are
shipping, we probably should just accept this and loosen the assertion.
Bug: 1457524
Reviewed-by: heycam
MozReview-Commit-ID: 9kFXBzLFAzE
The current code is mostly bechmarking Rust's default hash routines for
integers, which is not interesting to us. We add generating function
that jumps around "enough" and also add benchmarks for clear().
It's hard to read too much into the numbers because we can't reliably
simulate L1/L2 cache behavior with cargo bench, but the results show
about 40ns for clear() about 2ns for insert, and about 1.5ns for
contains/remove. This informs our thinking in the next patch.
