在 FindFirstFile-FindNextFile 中使用这个技巧加快文件搜索？答案

【问题标题】：Speed up file searching with this trick in FindFirstFile-FindNextFile?在 FindFirstFile-FindNextFile 中使用这个技巧加快文件搜索？
【发布时间】：2016-10-12 21:34:17
【问题描述】：

我想了解 FindFirstFile 和以下第一个 FindNextFile。是真的吗，FindFirstFile 总是找到“。” （当前文件夹）和以下 FindNextFile 总是“..”（父文件夹）？掩码当然是'*'。我想加快文件列表速度，我可以写一些东西吗，比如：

h := FindFirstFile('path\*' ...)     // it finds '.', not process
if h = INVALID_HANDLE_VALUE then ... // some error handling, of course
FindNextFile(...)                    // skipping '..', I suppose, if '.' has found,
                                     // '..' will be too, no handle validity check
while FindNextFile(...) do
  // file/folder processing begins here

所以我不需要检查 '.'和每个循环中的“..”文件名。对不起语法，我想我是可以理解的，如果我犯了错误，我的英语也很抱歉。

【问题讨论】：

这毫无意义，不会以任何可衡量的方式加速它，只会混淆。我也找不到任何可以保证订购的东西。简而言之，没有什么可以支持这样做的。
@DavidHeffernan 如果“路径”是“C:”，你就扔掉了两个非常好的目录条目。
加速枚举目录中文件的唯一真正方法是直接访问MFT。但是，事情变得复杂了，我不会打扰。
FindFirstFileEx 在某些情况下可能比FindFirstFile 更快。
这对于网络上的文件也可能会失败，具体取决于服务器运行的软件。

标签： winapi

【解决方案1】：

根本无法保证前两个条目是'. ' 和'..'。因此，您建议的代码无法使用。

我想，您可以在布尔值中记录您是否看过这两个条目，如果是，则跳过检查。

但是，检查这些值并不是您的瓶颈。枚举目录涉及访问磁盘和系统调用。这就是瓶颈。任何优化检查这些项目的尝试都会混淆您的代码并且不会产生明显的性能优势。

【讨论】：

【解决方案2】：

感谢您的回答。我的爱好之一是在简短的基本代码中找到最佳解决方案和算法（如果需要，可以到汇编级别）。在我的实践中，这似乎是真的，我经历过。但是没有找到任何关于它的文档，我想，这取决于 Find*File 内部行为和硬盘驱动器的数据结构。这就是我问的原因。再次感谢。

Jonathan：我确实将 FindFirstFileEx 与 FIND_FIRST_EX_LARGE_FETCH 一起使用，不像示例代码中那样 :) 我认为是否使用 Ex 与问题无关。

IInspectable：你说得对，我不想陷入 MFT :)

我不会使用这种形式的代码。我将使用 - 正如 David 所建议的 - 一个变量，但是一个整数类型来计算从 2 开始的出现次数，如果计数器达到 0，则不再需要名称检查。

【讨论】：

不会更快，而且你的代码会被混淆
我理解你，瓶颈，我无法加快 API 调用和磁盘访问，但我在反汇编器中跟踪了一个简单的字符串比较。这困扰（混淆:)我。请不要笑或认真对待我，这是一种爱好。我将编写一个专门的汇编代码来比较 unicode '.'和 '..'。可能我太极端了:)
这样做是为了好玩，但不要自欺欺人，您的程序会运行得更快。