Re: Benchmark of filesystem cache for index vs RAMDirectory...
Daniel Naber wrote: On Sunday 08 August 2004 03:40, Kevin A. Burton wrote: Would a HashMap implementation of RAMDirectory beat out a cached FSDirectory? It's easy to test, so it's worth a try. Please try if the attached patch makes any difference for you compared to the current implementation of RAMDirectory. True... I was just thinking out loud... was being lazy. Now I actually have to do the work to create the benchmark again... damn you ;) Kevin -- Please reply using PGP. http://peerfear.org/pubkey.asc NewsMonster - http://www.newsmonster.org/ Kevin A. Burton, Location - San Francisco, CA, Cell - 415.595.9965 AIM/YIM - sfburtonator, Web - http://peerfear.org/ GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412 IRC - freenode.net #infoanarchy | #p2p-hackers | #newsmonster
Re: Benchmark of filesystem cache for index vs RAMDirectory...
On Sunday 08 August 2004 03:40, Kevin A. Burton wrote:
> Would a HashMap implementation of RAMDirectory beat out a cached
> FSDirectory?
It's easy to test, so it's worth a try. Please try if the attached patch
makes any difference for you compared to the current implementation of
RAMDirectory.
Regards
Daniel
--
http://www.danielnaber.de
Index: RAMDirectory.java
===
RCS file: /home/cvs/jakarta-lucene/src/java/org/apache/lucene/store/RAMDirectory.java,v
retrieving revision 1.16
diff -u -r1.16 RAMDirectory.java
--- RAMDirectory.java 7 Aug 2004 11:19:28 - 1.16
+++ RAMDirectory.java 8 Aug 2004 09:01:19 -
@@ -18,8 +18,11 @@
import java.io.IOException;
import java.io.File;
+import java.util.HashMap;
import java.util.Hashtable;
import java.util.Enumeration;
+import java.util.Iterator;
+import java.util.Set;
import org.apache.lucene.store.Directory;
import org.apache.lucene.store.InputStream;
@@ -31,7 +34,7 @@
* @version $Id: RAMDirectory.java,v 1.16 2004/08/07 11:19:28 dnaber Exp $
*/
public final class RAMDirectory extends Directory {
- Hashtable files = new Hashtable();
+ HashMap files = new HashMap();
/** Constructs an empty [EMAIL PROTECTED] Directory}. */
public RAMDirectory() {
@@ -93,9 +96,11 @@
public final String[] list() {
String[] result = new String[files.size()];
int i = 0;
-Enumeration names = files.keys();
-while (names.hasMoreElements())
- result[i++] = (String)names.nextElement();
+Set names = files.keySet();
+for (Iterator iter = names.iterator(); iter.hasNext();) {
+ String element = (String) iter.next();
+ result[i++] = element;
+}
return result;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Benchmark of filesystem cache for index vs RAMDirectory...
I'm not sure how Solaris or Windows perform but the Linux block cache will essentially use all avali memory to buffer the filesystem. If one is using an FSDirectory to perform searches while the first search would be slow, remaining searches would be fast since Linux will now buffer the index in RAM. The RAMDirectory has the advantage of pre-loading everything and can keep it in memory if the box is performing other operations. In my benchmarks though RAMDirectory is slightly slower. I assume this is because its Hashtable based even though it only needs to be synchronized in a few places. IE searches should never be synchronized... Would a HashMap implementation of RAMDirectory beat out a cached FSDirectory? Kevin -- Please reply using PGP. http://peerfear.org/pubkey.asc NewsMonster - http://www.newsmonster.org/ Kevin A. Burton, Location - San Francisco, CA, Cell - 415.595.9965 AIM/YIM - sfburtonator, Web - http://peerfear.org/ GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412 IRC - freenode.net #infoanarchy | #p2p-hackers | #newsmonster - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
