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?
+1 I noticed that too, we should try to disable compression and compare results. alex On Wed, Apr 9, 2014 at 3:16 PM, Chetan Mehrotra <chetan.mehro...@gmail.com>wrote: > 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 >
