The RAMDirectory uses Java memory, an FSDirectory does not. Holding Java memory makes garbage collection work harder. The operating system is very very good at managing disk buffers, and does a better job using spare memory than Java does.
For real-world sites, RAMDirectory is almost always useless. Maybe the Instantiated index stuff is more what you want? Lance On Tue, Jun 7, 2011 at 2:52 AM, zhoucheng2008 <[email protected]> wrote: > Makes sense. Thanks > > -----Original Message----- > From: Toke Eskildsen [mailto:[email protected]] > Sent: Tuesday, June 07, 2011 4:28 PM > To: [email protected] > Subject: Re: RAMDirectory doesn't win over FSDirectory all the time, why? > > On Mon, 2011-06-06 at 15:29 +0200, zhoucheng2008 wrote: >> I read the lucene in action book and just tested the >> FSversusRAMDirectoryTest.java with the following uncommented: >> [...]Here is the output: >> >> RAMDirectory Time: 805 ms >> >> FSDirectory Time : 728 ms > > This is the code, right? > http://java.codefetch.com/example/in/LuceneInAction/src/lia/indexing/FSversusRAMDirectoryTest.java > > The test is problematic as the same two tests run sequentially. > > If you change > long ramTiming = timeIndexWriter(ramDir); > long fsTiming = timeIndexWriter(fsDir); > to > long fsTiming = timeIndexWriter(fsDir); > long ramTiming = timeIndexWriter(ramDir); > my guess is that RAMDirectory will be faster. For a better > comparison, perform each test in separate runs (make a test > class just for RAMDirectory and one just for FSDirectory, > then run them one at a time, each in its own JVM). > > One big problem when comparing RAMDirectory to file-access > is caching. What you measure with a test might not be what > you see in production, as the production index might be > large compared to RAM available for file caching. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Lance Norskog [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
