No I'm not comparing with Lucene 3.6 now with this configuration. It
is well known that Lucene 4 is significantly faster than Lucene 3, so
that would be unfair.
What is interesting is that when comparing our implementations vs. the
Apache stock ones while using Lucene 3 we where "very close", often a
bit faster but not too exciting.
Now comparing with the stock ones using Lucene 4 it seems we're
getting into a better position... and I didn't even profile it, this
is the first run after finishing coding the functional requirements.
Still these figures are produced by a stress test whose primary
purpose is to verify consistency and no-corruptions under stress.. I
happened to add some metrics for fun, but to provide realistic figures
one should run Lucene's own bench suite.. I'll do that next week.
@Manik yes I'm not using a CacheStore, I would presume the same. This
is why I've created the Lucene-specific CacheLoader, maybe I should
complete the job and make it a CacheStore.
Sanne
On 29 January 2013 13:14, Tristan Tarrant <ttarrant(a)redhat.com> wrote:
Have you got numbers comparing against Lucene 3.6 ?
Tristan
On 01/29/2013 12:53 AM, Sanne Grinovero wrote:
> These are preliminary results of our stressor; looks quite promising
> as I haven't yet looked into profiling / tuning:
>
> Stock Lucene RAMDirectory
> Searches: 14.799.852
> Writes: 195.935
>
> Stock Lucene FSDirectory (Memory mapping on SSD)
> Searches: 9.628.593
> Writes: 105.930
>
> Our custom Infinispan Directory (LOCAL)
> Searches: 17.815.874
> Writes: 184.140
>
> Figures represent operations performed in 15 minutes on a relatively
> small index.
>
> Cheers,
> Sanne
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev