On Tuesday, Feb 25, 2003, at 09:43 Europe/Zurich, Andrzej Bialecki wrote:
No, I'm not - this is clearly stated in the class javadoc. I meant to try it out in my application, but haven't got to it yet - I need to address first the base functionality, not performance; so, I don't have the modified FSDirectory yet... The class is taken from Multivalent browser, and is subject to BSD-equivalent license - which means you can use it for whatever purpose, and if it turns out to be useful, it can be included in Lucene distribution.
"Ask and ye shall get a random piece of somebody else mind"... and it just so happen that recently I did some (not so rigorous) testing using Multivalent's phelps.io.BufferedRandomAccessFile... and I'm happy to report that... I doesn't seems to make a shred of difference in my case... but as always YMMV.
This is strange, or at least counter-intuitive - if you buffer larger parts of data in RAM than the standard implementation does, it should definitely be faster... Let's wait and see what Terry comes up with.
BTW. how large indexes did you use for testing? Also, it could be that the indexing process is bound by some other bottleneck, and buffering helps only when searching already existing index.
-- Best regards, Andrzej Bialecki
------------------------------------------------- Software Architect, System Integration Specialist ------------------------------------------------- FreeBSD developer (http://www.freebsd.org)
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
