runtime: .NET Core 2.1 remote directory enumeration with filters can be slower than prior frameworks

@ONeill45 commented on Tue Sep 04 2018

Issue Title

.NET Core 2.1 DirectoryInfo.EnumerateFiles() Performance is Slower than .NET Framework

General

I have a .NET Core 2.1 Web API that is being built as a replacement for an older .NET Framework MVC Web Application (.NET Framework 4.5).

One of the responsibilities of this application is to take in a directory and search template and return the top 10 results, ordered by most recent. This is being accomplished using System.IO.DirectoryInfo and the EnumerateFiles() method:


List<FileInfo> fileInfos = new DirectoryInfo(directory).EnumerateFiles(fileTemplate)
.OrderByDescending(f => f.LastWriteTime).Take(10).ToList();

However, I am noticing that this search is much, much slower in .NET Core than in .NET Framework. I created two console apps with the same code, one .NET Framework and one .NET core, to compare run times. Below are the results in .NET Framework:

And then the results in .NET Core:

Can anyone help me understand why there is such a dramatic decrease in performance?

@MarcoRossignoli commented on Tue Sep 04 2018

better move to https://github.com/dotnet/corefx

/cc @JeremyKuhne, @pjanotti

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 19 (11 by maintainers)

Most upvoted comments

Altering the BufferSize in the EnumerationOptions class made a huge difference.

Cool. It is always nice to see features work the way they’re intended. 😉

Any advice on how to best determine proper buffer size?

Make it big enough to handle the expected file count. You’ll have to measure to see for sure where the sweet spot is for your scenario. The buffer is rented from the ArrayPool and as such is reused (and collected if left idle)- don’t sweat the size too much.

Some of this might be fallout of .NET doing the matching. I might just need to tweak up the default size. What diff does 8K make for you?

JeremyKuhne on Sep 10, 2018