lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Index in RAM - is it realy worthy?
Date Wed, 24 Nov 2004 09:27:35 GMT
Thanks everybody for responds.

What else can essentially improve queries performance?
(I do not speak now about such things as keeping index optimized etc. - 
it's clear)

As I experiensed on my 2 cpu box,  during the query execution both 
processors were realy busy. The question is would it accelerate speed if I 
get 4 cpu box, 10 cpu...
I mean real performance boost (at least factor 10), not just %-ge.

Whould it help if I play with different query formulation, i.e.  "a and (b 
or c)" instead of  "(b or c) and a"


"Kevin A. Burton" <>
22.11.2004 21:40
Please respond to "Lucene Users List"

        To:     Lucene Users List <>
        cc:     (bcc: Iouli Golovatyi/X/GP/Novartis)
        Subject:        Re: Index in RAM - is it realy worthy?

Otis Gospodnetic wrote:

>For the Lucene book I wrote some test cases that compare FSDirectory
>and RAMDirectory.  What I found was that with certain settings
>FSDirectory was almost as fast as RAMDirectory.  Personally, I would
>push FSDirectory and hope that the OS and the Filesystem do their share
>of work and caching for me before looking for ways to optimize my code.
Also another note is that doing an index merge in memory is probably 
faster if you just use a RAMDirectory and perform addIndexes to it.

This would almost certainly be faster than optimizing on disk but I 
haven't benchmarked it.



Use Rojo (RSS/Atom aggregator).  Visit Ask me for an 
invite!  Also see #rojo if you want to chat.

Rojo is Hiring! -

If you're interested in RSS, Weblogs, Social Networking, etc... then you 
should work for Rojo!  If you recommend someone and we hire them you'll 
get a free iPod!
Kevin A. Burton, Location - San Francisco, CA
       AIM/YIM - sfburtonator,  Web -
GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412

To unsubscribe, e-mail:
For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message