On Wed, Apr 9, 2014 at 5:14 PM, Jukka Zitting <jukka.zitt...@gmail.com> wrote: > Is that a common use case? To better simulate a normal usage scenario > I'd make the benchmark fetch up to N results (where N is configurable, > with default something like 20) and access the path and the title > property of the matching nodes.
I changed the logic of benchmark in http://svn.apache.org/r1585962. With that JR2 slows down a bit # FullTextSearchTest C min 10% 50% 90% max N Oak-Tar 1 34 35 36 39 60 1639 Jackrabbit 1 5 5 6 7 68 10038 Profiling the result shows that quite a bit of time goes in org.apache.lucene.codecs.compressing.LZ4.decompress() (40%). This I think is part of Lucene 4.x and not present in 3.x. Any idea if I can disable compression? Chetan Mehrotra
