Calling op.apply on an op we know to be an add ends up noticably
increasing the cost of the operation; this trivial change gets about
a 5-10% reduction in reported runtime of benchmarks doing a lot
of adds. (The other IntersectionCount benchmarks don't actually use
Add most of the time, so it doesn't show up in them.)
name old time/op new time/op delta
GetBenchData-8 4.25ms ± 0% 3.91ms ± 2% -8.04% (p=0.002 n=6+6)
Bitmap_IntersectionCount_ArrayArray-8 20.9µs ± 2% 18.7µs ± 3% -10.18% (p=0.004 n=5+6)
SliceAscending-8 24.7ms ± 0% 21.8ms ± 0% -11.74% (p=0.004 n=5+6)
SliceDescending-8 29.8ms ± 0% 27.0ms ± 0% -9.56% (p=0.004 n=5+6)
SliceAscendingStriped-8 32.0ms ± 0% 29.5ms ± 0% -8.07% (p=0.008 n=5+5)
SliceDescendingStriped-8 39.3ms ± 1% 36.8ms ± 1% -6.27% (p=0.002 n=6+6)
Two changes: First, make SliceDescending set the entire
slice, not all-but-one bits. Second, add tests that are
"striped", so it's writing to 8 parts of the slice
sequentially, rather than just going up or down the whole
thing, because that gives us some cheap indication of
cache-locality impact, which turns out to be possibly
significant.
I am aware that I don't actually ever use the length of a
after this line of code, but if I don't correctly update it,
any future change that needs that length will break
mysteriously. We humbly ask gometalinter to consider
the reply of counsel in _Arkell v. Pressdram_ (1971).
A transient bug introduced in intersectionCountArrayArray was
not caught by the tests, because it would only manifest when
two containers of different lengths were being compared. Also
improve the testing for intersectArrayArray, even though that
code hasn't been changed.
Roaring likes to call things "a" and "b", not "1" and "2",
and use "n" for length, not "l", etcetera. Adopt these
conventions to make code more readable.
Also drop the 'vb' value since it isn't expensive to
compute and the compiler can figure out that it can
reuse the value.
