Screaming fast Lucene searches using C++ via JNI
At the end of the day, when Lucene executes a query, after the initial setup the true hot-spot is usually rather basic code that decodes sequential blocks of integer docIDs, term frequencies and positions, matches them (e.g. taking union or intersection for
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
BooleanQueryis optimized, but only when all clauses are
TermQueryagainst 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.
- Code specialization: lucene-c-boost 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 gains.
- 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
IndexReaderwhile other threads are still using it, the process will hit a Segmentation 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
PostingsFormatstores 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
PostingsFormatbetter optimized for the CPU at search time. Positional queries, Filters and nested
BooleanQueryare not yet optimized, as well as certain configurations (e.g., fields that omit norms). Patches welcome!
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.