BooleanQuery), computes a score for each hit and
finally saves the hit if it's competitive, during collection.
Even apparently complex queries like
WildcardQuery go through a rewrite process that
reduces them to much simpler forms like
Lucene's hot-spots are so simple that optimizing them by porting them to native C++ (via JNI) was too tempting!
So I did just that, creating the lucene-c-boost github project, and the resulting speedups are exciting:
These results are on the full, multi-segment Wikipedia English index with 33.3 M documents. Besides the amazing speedups, it's also nice to see that the variance (StdDev column) is generally lower with the optimized C++ version, because hotspot has (mostly) been taken out of the equation.
The API is easy to use, and works with the default codec so you won't have to re-index just to try it out: instead of
NativeSearch.search. If the query can be optimized, it
will be; otherwise it will seamlessly fallback to
IndexSearcher.search. It's fully decoupled from Lucene
and works with the stock Lucene 4.3.0 JAR, using Java's reflection
APIs to grab the necessary bits.
This is all very new code, and I'm sure there are plenty of exciting bugs, but (after some fun debugging!) all Lucene core tests now pass when using
This is not a C++ port of Lucene
This code is definitely not a general C++ port of Lucene. Rather, it implements a very narrow set of classes, specifically the common query types. The implementations are not general-purpose: they hardwire (specialize) specific code, removing all abstractions like
There are some major restrictions on when the optimizations will apply:
- Only tested on Linux and Intel CPU so far
- Requires Lucene 4.3.x
- Must use
Directoryimplementation, which maps entire files into RAM (avoids the chunking that the Java-based
- Must use the default codec
- Only sort by score is supported
- None of the optimized implementations use
advance: first, this code is rather complex and will be quite a bit of work to port to C++, and second, queries that benefit from advance are generally quite fast already so we may as well leave them in Java
BooleanQuery is optimized, but only when all clauses
TermQuery against the same field.
C++ is not faster than java!
Not necessarily, anyway: before anyone goes off screaming how these results "prove" Java is so much slower than C++, remember that this is far from a "pure" C++ vs Java test. There are at least these three separate changes mixed in:
- Algorithmic changes. For example, lucene-c-boost sometimes uses
BooleanScorerwhere Lucene is using
BooleanScorer2. Really we need to fix Lucene to do similar algorithmic changes (when they are faster). In particular, all of the
OrXXqueries that include a
Notclause, as well as
IntNRQin the above results, benefit from algorithmic changes.
implements the searches as big hardwired scary-looking functions,
removing all the nice Lucene abstractions. While abstractions
are obviously necessary in Lucene, they unfortunately add
run-time cost overhead, so removing these abstractions gives some
- C++ vs java.
This code is dangerous!
Specifically, whenever native C++ code is embedded in Java, there is always the risk of all those fun problems with C++ that we Java developers thought we left behind. For example, if there are bugs (likely!), or even innocent API mis-use by the application such as accidentally closing an
IndexReader while other threads
are still using it, the process will hit
Fault and the OS will destroy the JVM. There may also be memory
leaks! And, yes, the C++ sources even use
the goto statement.
Work in progress...
This is a work in progress and there are still many ideas to explore. For example, Lucene 4.3.x's default
PostingsFormat stores big-endian longs, which means the
little-endian Intel CPU must do byte-swapping when decoding each
postings block, so one thing to try is a
better optimized for the CPU at search time. Positional queries,
Filters and nested
BooleanQuery are not yet optimized, as well as
certain configurations (e.g., fields that omit norms). Patches
Nevertheless, initial results are very promising, and if you are willing to risk the dangers in exchange for massive speedups please give it a whirl and report back.