Well, yeah, that's a lot more than I realized.. My assumption was that there wouldn't be more FileInfo objects created than there were files created, which is not that many. Whatever is doing that should be re-written to pass the obj vs recreating it.
-T On Thu, Jun 14, 2012 at 3:57 PM, Christopher Currens <currens.ch...@gmail.com> wrote: > They're used more than it looks like they are. One of the largest ways > they're used in the Store namespace is *to create FileStream > objects*...which is such a waste of an allocation. A small test program I > wrote created ~1000 FileInfo objects every minute, most of that thanks to > merging. Considering the other object allocations in the library, though, > it's unlikely removing them *alone* will do anything measurable to > performance. But I disagree that it shouldn't be a concern. That kind of > attitude will kill our performance if applied to other areas of the code. > > > Thanks, > Christopher > > On Thu, Jun 14, 2012 at 2:23 PM, Troy Howard <thowar...@gmail.com> wrote: > >> +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 >> >> > >> >> > >> >> >>
