这是Windows 7,64位，专业使用
考虑一个非常简单的循环
for (i = 0; i < names->size(); i++) { std::string Name = names->at(i); HANDLE fileHandle = CreateFile(Name.c_str(), GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL); if (fileHandle == INVALID_HANDLE_VALUE) { throw "Failed"; } CloseHandle(fileHandle); } 如果我在一个有863个文件的目录上运行它，它会稍微超过22秒，或25毫秒/文件。 下一次169毫秒或0.19毫秒/文件。 如果我只是使用find_file的时间，新鲜的目录是非常快的，约0.2毫秒/文件。 虽然我在这里使用了CreateFile，但其他方法的结果相同。
当然，答案是文件caching：Windows必须caching关于文件打开的信息。 而且，它必须是磁盘访问，就像目录在SSD上一样，第一次和第二次打开大致相同。
现在这些硬盘上的查找时间只有9毫秒，所以有人知道WINDOWS在25毫秒的时间里只有在没有读数的情况下打开/closures一个文件才能读取。 但更重要的是，是否有可能加快速度。 你可能会说25 ms很快，但是我正在播放video文件，所以我需要在33 ms左右读取数据，实际读取的数据在30 ms范围内，所以打开成本太高。
任何build议如何快速打开* *文件的负载，将不胜感激。
当你打开一个文件的时候，Windows会做很多事情 。 我不是专家，但我可以提到文件系统维护（更新访问时间，日志等）和访问权限检查作为两个重要项目。 不幸的是，我不认为你可以做得更快。
当然，如果您不打算从文件中读取任何内容，而只是检查文件是否存在或读取某些元数据（如修改时间），则可以在不打开文件的情况下快速执行此操作。
我不认为这个答案应该被接受。 原来的问题是“为什么它第一次放慢呢？” 操作系统必须执行相同的维护/日志/检查/等。 无论是第一次还是第二十次。
我在java下看到完全一样的东西。 第一次运行一个程序，一个接一个地打开4000个文件，Profiler显示我花了96.4％的程序时间在sun.nio.fs.WindowsNativeDispatcher.CreateFile0 [native]（long，int，int，long，int ，int）。
然后，如果我立即再次运行，它运行速度快20倍，分析器显示我甚至没有使用CreateFile。 事实上，JVM正在选择完全不同的对象和方法来完成Files.readAllLines调用。
我怀疑OP是经验类似的东西，而不是日常的操作系统维护要求。