Beeinflusster FieldCache-Lasttest: Lucene 2.4 VS Lucene 2.9

*edit* Tut mir leid – ich habe mit meinem ursprünglichen Testcode etwas übereilt gehandelt – Sie müssen den IndexWriter nach der Optimierung schließen! Die Vorteile sind nur bei Indizes mit mehreren Segmenten gegeben. Der korrigierte Eintrag folgt:

Lassen Sie uns einen kleinen Test machen. Wir werden einen FieldCache mit 5.000.000 eindeutigen Strings laden und sehen, wie lange Lucene 2.4 im Vergleich zu Lucene 2.9 braucht.

Lassen Sie uns meinen Quad-Core-Laptop und den folgenden Testcode verwenden:

public class ContrivedFCTest extends TestCase {
  public void testLoadTime() throws Exception {
    Directory dir = FSDirectory.getDirectory(System.getProperty("java.io.tmpdir") + File.separator + "test");
    IndexWriter writer = new IndexWriter (dir, new SimpleAnalyzer(), true, IndexWriter.MaxFieldLength.LIMITED);
    writer.setMergeFactor(37);
    writer.setUseCompoundFile(false);
    for(int i = 0; i < 5000000; i++) {
      Document doc = new Document();
      doc.add (new Field ("field",  "String" + i, Field.Store.NO, Field.Index.NOT_ANALYZED));
      writer.addDocument(doc);
    }
    writer.close();

    IndexReader reader = IndexReader.open(dir);
    long start = System.currentTimeMillis();
    FieldCache.DEFAULT.getStrings(reader, "field");
    long end = System.currentTimeMillis();
    System.out.println("load time:" + (end - start)/1000.0f + "s");
  }
}

Die Ergebnisse?

Lucene 2.4: 150.726s
Lucene 2.9: 9.695s

Wir haben Anfang des Jahres festgestellt, dass Lucene in der Vergangenheit beim Laden von FieldCaches über mehrere Segmente hinweg sehr ineffizient war. Lucene 2.9 behebt dieses Problem auf der MultiReader-Ebene (vielen Dank an Yonik!). Außerdem wird der interne FieldCache jetzt pro Segment verwendet, wodurch das Laden von FieldCaches über mehrere Segmente hinweg vermieden wird – jedes Segment hat seinen eigenen FieldCache.