I read his complete article... he still doesn't have a clue. The opening and closing of the IndexReader's is just creating garbage which is distorting the memory consumption, and ruining the performance - it is akin to starting it from the command-line to perform a search. As you state, the Java memory consumption will continue to grow until it hits the Xmx until it even attempts to purge, and even then it may not release the memory back to the OS. Even small one-time use strings will eventually show huge memory consumption until the runtime needs the memory.
It is my understanding in reviewing the Lucene code, is that Lucene caches VERY LITTLE information in memory - seemingly just the skip table for terms, and relies on the OS's disk cache for performance (other than the new enhancements I posted that move a cache into the Lucene directory). Maybe somebody has more information here? Robert Engels -----Original Message----- From: Daniel Naber [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 01, 2005 5:07 PM To: java-dev@lucene.apache.org Subject: Re: Lucene vs. Ruby/Odeum On Tuesday 17 May 2005 04:41, Otis Gospodnetic wrote: > http://www.zedshaw.com/projects/ruby_odeum/performance.html Here's a follow up: http://www.zedshaw.com/projects/ruby_odeum/odeum_lucene_part2.html Now the claim is that Lucene is faster than Ruby/Odeum but it takes 36 times more memory. However, I cannot find any information on how exactly Lucene was started. It's no surprise that Java requires much memory and doesn't clean up if it never comes close to the limit set with -Xmx. Regards Daniel -- http://www.danielnaber.de --------------------------------------------------------------------- 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]
