lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Currens <currens.ch...@gmail.com>
Subject Re: svn commit: r1350178 - /incubator/lucene.net/trunk/src/core/Store/FSDirectory.cs
Date Thu, 14 Jun 2012 16:39:41 GMT
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 <itamar@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 <bodewig@apache.org>
> wrote:
>
> > On 2012-06-14, <synhershko@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
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message