I ran a quick benchmark on faceting (which uses FixedBitSet a lot) and the
results seem to be in the noise, at least on the server I ran. Maybe on a
32-bit system it would show different results, but I don't have any. What I
measured is FixedBitSet cutover to long instead of int:
Task QPS base StdDev QPS comp
StdDev Pct diff
IntNRQ 9.18 (5.0%) 8.87 (4.6%)
-3.4% ( -12% - 6%)
Prefix3 96.44 (4.0%) 94.40 (3.6%)
-2.1% ( -9% - 5%)
OrNotHighMed 18.00 (4.4%) 17.80 (4.9%)
-1.2% ( -10% - 8%)
OrNotHighHigh 13.10 (3.5%) 12.95 (3.9%)
-1.1% ( -8% - 6%)
OrHighHigh 3.77 (3.1%) 3.73 (3.3%)
-1.0% ( -7% - 5%)
OrHighLow 5.48 (3.1%) 5.43 (3.3%)
-1.0% ( -7% - 5%)
OrNotHighLow 29.77 (5.5%) 29.51 (5.9%)
-0.9% ( -11% - 11%)
OrHighNotHigh 8.00 (3.1%) 7.94 (3.6%)
-0.8% ( -7% - 6%)
OrHighNotLow 9.18 (3.0%) 9.11 (3.3%)
-0.7% ( -6% - 5%)
Wildcard 14.27 (3.6%) 14.18 (3.2%)
-0.6% ( -7% - 6%)
OrHighMed 12.03 (2.8%) 11.98 (3.2%)
-0.4% ( -6% - 5%)
Fuzzy2 25.42 (2.9%) 25.34 (2.6%)
-0.3% ( -5% - 5%)
AndHighHigh 15.96 (1.7%) 15.97 (2.2%)
0.0% ( -3% - 3%)
Respell 24.37 (2.7%) 24.42 (3.3%)
0.2% ( -5% - 6%)
AndHighMed 16.29 (2.1%) 16.33 (2.1%)
0.2% ( -3% - 4%)
OrHighNotMed 14.60 (2.9%) 14.64 (3.1%)
0.3% ( -5% - 6%)
MedSloppyPhrase 1.68 (7.7%) 1.68 (6.3%)
0.3% ( -12% - 15%)
LowSpanNear 4.59 (4.0%) 4.61 (4.8%)
0.3% ( -8% - 9%)
LowSloppyPhrase 20.66 (2.7%) 20.75 (2.5%)
0.4% ( -4% - 5%)
MedSpanNear 14.86 (4.1%) 14.94 (4.6%)
0.6% ( -7% - 9%)
HighSloppyPhrase 1.80 (10.1%) 1.81 (9.1%)
0.7% ( -16% - 22%)
LowPhrase 5.77 (7.3%) 5.82 (7.5%)
0.8% ( -13% - 16%)
LowTerm 99.61 (5.5%) 100.41 (4.7%)
0.8% ( -8% - 11%)
HighSpanNear 3.71 (4.8%) 3.75 (6.7%)
1.0% ( -10% - 13%)
MedPhrase 79.50 (7.0%) 80.33 (6.9%)
1.0% ( -11% - 16%)
HighPhrase 2.29 (10.1%) 2.32 (10.2%)
1.3% ( -17% - 23%)
Fuzzy1 35.61 (2.4%) 36.07 (3.3%)
1.3% ( -4% - 7%)
MedTerm 26.49 (3.9%) 26.84 (4.2%)
1.3% ( -6% - 9%)
HighTerm 22.04 (3.1%) 22.35 (3.1%)
1.4% ( -4% - 7%)
AndHighLow 195.41 (2.7%) 199.15 (4.0%)
1.9% ( -4% - 8%)
There are two issues though, both come from Bits: length() returns an
integer and get() takes an integer.
Maybe we shouldn't change FixedBitSet, but instead create a new LongBitSet
or something which is not elastic, and doesn't let you trip on the
differences between set/fastSet. It only has set, doesn't implement Bits,
doesn't extend DocIdSet (which makes no sense anyway). We then use
FixedBitSet for the "docs" bits and LongBitSet e.g.in DVConsumer, Terms --
wherever the size is known in advance.
We can then review the places which rely on elasticity and decide if OBS is
still needed or not.
Shai
On Thu, Feb 6, 2014 at 12:38 PM, Michael McCandless <
[email protected]> wrote:
> Wow, those gains are substantial:
>
> PrefixQuery
> http://people.apache.org/~mikemccand/lucenebench/Prefix3.html
>
> WildcardQuery
> http://people.apache.org/~mikemccand/lucenebench/Wildcard.html
>
> I will add an annotation for this change :)
>
> The motivation for FBS was to store docIDs, and since those are
> limited to a java int, we used an int index back then.
>
> You're right that OpenBitSet has "elasticity", but one could also
> achieve that by growing a FBS. Maybe it should be renamed to
> ElasticBitSet.
>
> It does also allow long bit sets ... probably if we added
> get/set(long) to FBS that wouldn't hurt performance? If we replaced
> get/set(int) with get/set(long) I'm not sure...
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Thu, Feb 6, 2014 at 3:39 AM, Shai Erera <[email protected]> wrote:
> > Hi
> >
> > I recently modified FixedBitSet.iterator() to return its own iterator,
> > instead of OpenBitSetIterator, and while I haven't done a thorough
> > performance test, the results on LUCENE-5425 suggested this helped in
> > general (even though we only tested facets). Also, last night's benchmark
> > for WildcardQuery and PrefixQuery indicate a 20% jump in QPS.
> >
> > This got me thinking (again) why do we keep both bitsets, and whether we
> > couldn't live with just one. So clearly FBS is faster than OBS (perhaps
> > unless you use fastSet/Get) since it doesn't need to do bounds checking.
> > Also, FBS lets your grow itself by offering a convenient copy constructor
> > which allows to expand/shrink the set.
> >
> > OpenBigSet however lets you manage 64 * 2^32 bits, while FixedBitSet only
> > allows managing 2^32 bits. Is there any reason for this? Besides the fact
> > that neither can return a DISI over more than 2^32-1 bits/docs, I don't
> see
> > any real reason for that. We'll need to change FBS API to take/return
> long,
> > but besides that?
> >
> > I did a quick search on the usage of OpenBitSet and eclipse found 272
> > mentions of it. I believe some, if not all, of these uses can be
> replaced by
> > FixedBitSet. Definitely when the number of bits is known in advance, but
> I
> > think also when it's not known, by growing the bitset.
> >
> > One place I found is DocValuesConsumer, which clearly knows the number of
> > bits in advance (dv.getValueCount()), however this returns a long, so
> this
> > prevents cutting over to FBS immediately, but if we allow FBS to handle
> > longs, I think that we can?
> >
> > Anyway, wanted to get your thoughts before I open an issue and start this
> > work.
> >
> > Shai
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
