+1  on the string vs DirectoryInfo overload, Iatmar

Re: Comments and JVM, I'd suggest editing the .NET comments to remove
Java specific recommendations/concerns. We're not running on the JVM,
so consumes of our code don't need that info.

Re: GC pressure on the File/DirectoryInfo objects.. There's so few of
them it really doesn't make a difference. That aspect of their usage
should not be a concern. A greater concern is that they don't really
support the full range of Win32API file access (eg long paths, etc).

Thanks,
Troy


On Thu, Jun 14, 2012 at 9:39 AM, Christopher Currens
<currens.ch...@gmail.com> wrote:
> 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
>> >
>> >
>>

Reply via email to