UNC Path Appears To Slow File Enumeration Considerably

问题

I have written a sample application to debug an issue with enumerating files.

Enumerating a directory with a local path (eg C:\Data\MAN) enumerates considerably quicker than a shared directory with a UNC path (eg \\MACHINENAME\man). Even though these paths both point to the same directory on the local machine.

With 72000 files, this takes approx 10 seconds:

DirectoryInfo directoryInfo = new DirectoryInfo(@"C:\Data\MAN");
FileInfo[] fileInfoTest = directoryInfo.GetFiles("*.*", 
                                                 SearchOption.AllDirectories);

With 72000 files, this takes approx 2 minutes: (where \\MACHINENAME\man is shared folder C:\Data\MAN)

DirectoryInfo directoryInfo = new DirectoryInfo(@"\\MACHINENAME\man");
FileInfo[] fileInfoTest = directoryInfo.GetFiles("*.*", 
                                                 SearchOption.AllDirectories);

Is this amount of overhead expected when using a UNC path?

回答1:

This is an old question and the comments seem to get half way there but there's no reason not to try and attempt to answer this. The file count here is part of the issue in that there are 72,000 of them. So what's going on?

Well, as already answered here, it essentially comes down to context switching between the different processes that are used when dealing with UNC paths over local paths, specifically the calling process and the SMB client + server processes. This boils down to: direct is faster. Don't go via UNC if it's a local resource, and, obviously, the more files involved the slower it'll be.

来源：https://stackoverflow.com/questions/14361150/unc-path-appears-to-slow-file-enumeration-considerably

标签

unc