That comment is correct. We don't have support for NIOFSDirectory in .NET (and the JVM support for it in windows has a major bug). We also don't support MMapDirectory, because we haven't bothered to support it yet. I think digy ported it once, but it didn't add any speed benefits, and was actually fairly slower than the FSDirectory classes.
It wasn't that long ago that we had the string constructors for Directory classes. I think they were in the java code and then replace with File (DirectoryInfo for .NET). I've always hated passing in DirectoryInfo, and I don't really understand why it's in the code. It doesn't seem to give much added benefit, if any. You can pass a string that is a path to an existing file and it will still create the DirectoryInfo object. I would think (but don't know) it would be better for performance to *not* use the File and Directory classes (I'm actually not sure how deep the usages of these classes go, so I'm not sure what difference it would make), since it results in added pressure on the GC with the extra object creations. +1 to this. On Thu, Jun 14, 2012 at 5:25 AM, Itamar Syn-Hershko <ita...@code972.com>wrote: > I'd assume so, at least partially > > I just copy-pasted from one method below > > On Thu, Jun 14, 2012 at 2:52 PM, Stefan Bodewig <bode...@apache.org> > wrote: > > > On 2012-06-14, <synhers...@apache.org> wrote: > > > > >> /// <p/>Currently this returns <see > > cref="SimpleFSDirectory" /> as > > >> /// NIOFSDirectory is currently not supported. > > >> /// > > >> /// <p/><b>NOTE</b>: this method may suddenly change > which > > >> /// implementation is returned from release to release, > in > > >> /// the event that higher performance defaults become > > >> /// possible; if the precise implementation is important > to > > >> /// your application, please instantiate it directly, > > >> /// instead. On 64 bit systems, it may also good to > > >> /// return <see cref="MMapDirectory" />, but this is > > disabled > > >> /// because of officially missing unmap support in Java. > > >> /// For optimal performance you should consider using > > >> /// this implementation on 64 bit JVMs. > > > > Does this apply to the .NET code? > > > > Stefan > > > > >
