This uses a bitmap representation instead of a list if the density of
the list is high enough (at least 1 in 32, which is the breakeven point
sizewise).
Experimenting with the LLVM index, this saves about 3% of total posting
list size, which isn't worth the complexity.
However it should also improve iterator performance somewhat:
- advance is within a constant factor (find next set bit, average step is bounded)
- advanceTo is constant time instead of log(n) with random accesses
If the posting lists that are dense are also commonly used in queries
(seems likely for common trigrams) then this may be worth doing for
latency reasons.
I'm uploading this so Kirill can experiment with benchmarks.