lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yonik Seeley" <>
Subject Re: [jira] Updated: (LUCENE-584) Decouple Filter from BitSet
Date Tue, 05 Sep 2006 21:15:42 GMT
On 9/4/06, Eks Dev (JIRA) <> wrote:

> Here are some Matcher implementations,
> - OpenBitsMatcher- the same as the code Paul wrote for BitsMatcher, with replaced OpenBitSet
> -DenseOpenBitsMatcher  - Using solr BitSetIterator (for skipTo() to work, one method
in BitSetIterator should become public)

Keep in mind that BitSetIterator is fast for iteration over all it's bits.
If it's used as a filter (with skipping), I would expect it to be slower.

> Also attached one simple  test (just basic fuctionality) that also contains one dummy
relative performance  test
> Perf. test simply iterates over different Matcher implementations  and measures ellapsed
time (not including Matcher creation, pure forward scan to the end) for different set bit
> imho, this code is not sufficiantly tested nor commented, needs an hour or two.
> As expected, Yonik made this BitSetIterator really fast. What was surprise for me was
OpenBitSet nextSetBit() comparing bad to the BitSet  (or I made some dummy mistake somewhere?)

That's weird... what CPU and in what mode (32 or 64 bit)?  What JVM params?
Do you get the same results from org.apache.solr.util.BitSetPerf for nextSetBit?

I did write it on a P4, and ntz (number of trailing zeros) is
currently optimized for a 32 bit CPU where a 64 bit shift may be
slightly more expensive.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message