为什么 EnumerateFiles 比计算大小快得多

对于我的 WPF 项目，我必须计算单个目录（可能有子目录）中的总文件大小。

Sample 1

DirectoryInfo di = new DirectoryInfo(path);
var totalLength = di.EnumerateFiles("*.*", SearchOption.AllDirectories).Sum(fi => fi.Length);

if (totalLength / 1000000 >= size)
    return true;

Sample 2

 var sizeOfHtmlDirectory = Directory.GetFiles(path, "*.*", SearchOption.AllDirectories);
 long totalLength = 0;
 foreach (var file in sizeOfHtmlDirectory)
 {
     totalLength += new FileInfo(file).Length;
     if (totalLength / 1000000 >= size)
         return true;
 }

两个样本都有效。

示例 1 的完成时间要快得多。我没有准确地计时，但在我的电脑上，使用具有相同内容/文件大小的同一文件夹，示例 1 需要几秒钟，示例 2 需要几分钟。

EDIT

我应该指出，示例 2 中的瓶颈位于 foreach 循环内！它快速读取 GetFiles 并快速进入 foreach 循环。

我的问题是，我如何找出为什么会出现这种情况？

与其他答案所表明的相反，主要区别不是EnumerateFiles vs GetFiles - it's DirectoryInfo vs Directory- 在后一种情况下，您只有字符串并且必须创建新的FileInfo单独的实例，成本非常高。

DirectoryInfo回报FileInfo使用缓存信息的实例与直接创建新信息的实例FileInfo不存在的实例 - 更多详细信息here http://blogs.msdn.com/b/oldnewthing/archive/2011/12/26/10251026.aspx and here https://stackoverflow.com/questions/7828132/getting-current-file-length-fileinfo-length-caching-and-stale-information.

相关引用（来自“旧新事物”）：

在 NTFS 中，文件系统元数据是一个属性，而不是目录项的属性 而是文件的一部分，其中一些元数据被复制到 目录条目作为改进目录枚举的调整 表现。 FindFirstFile 等函数报告目录 条目，并通过放置 FAT 用户习惯的元数据 “免费”获得，他们可以避免比 FAT 慢 目录列表。目录枚举函数报告 最后更新的元数据，可能与实际元数据不对应 如果目录条目已过时。