我正在编写一个程序，应该处理许多小文件，比如说数千甚至数百万。
我一直在 500k 文件上测试该部分，第一步只是迭代一个目录，其中包含大约 45k 目录（包括子目录的子目录等）和 500k 小文件。遍历所有目录和文件，包括获取文件大小和计算总大小大约需要6秒。现在，如果我尝试在遍历时打开每个文件并立即关闭它，看起来它永远不会停止。事实上，这需要太长的时间（几个小时......）。由于我在 Windows 上执行此操作，因此我尝试使用 CreateFileW、_wfopen 和 _wopen 打开文件。我没有在文件上读取或写入任何内容，尽管在最终实现中我只需要读取。然而，我没有看到任何尝试有明显的改进。
我想知道是否有一种更有效的方法来使用任何可用的函数（无论是 C、C++ 还是 Windows API）打开文件，或者唯一更有效的方法是直接读取 MFT 并读取磁盘块，我是这样的我试图避免？
更新：我正在开发的应用程序正在使用版本控制进行备份快照。所以，它也有增量备份。 500k 文件的测试是在一个巨大的源代码存储库上完成的，以便进行版本控制，类似于 scm。因此，所有文件都不在一个目录中。还有大约 45k 个目录（如上所述）。
因此，建议的压缩文件的解决方案没有帮助，因为备份完成后，所有文件都将被访问。因此，我不会从中看到任何好处，甚至会产生一些性能成本。
你想做的事情本质上是困难的any操作系统能够高效地完成任务。 45,000 个子目录无论如何切片都需要大量磁盘访问。
对于 NTFS 而言，任何超过 1,000 字节的文件都是“大”文件。如果有办法让大部分数据文件少于 900 左右bytes，您可以通过将文件数据存储在MFT内来实现显着的效率。那么获取数据不会比获取文件的时间戳或大小更昂贵。
我怀疑是否有任何方法可以优化程序的参数、进程选项，甚至操作系统的调整参数，以使应用程序正常运行。您将面临数小时的操作，除非您能以完全不同的方式重新构建它。
一种策略是将文件分布在多台计算机（可能是数千台计算机）上，并在每台处理本地文件的计算机上都有一个子应用程序，将任何结果提供给主应用程序。
另一种策略是将所有文件重新构建为几个更大的文件，例如 @felicepollano 建议的大 .zip 文件，从而有效地虚拟化您的文件集。随机访问 4000 GB 文件本质上比访问 40 亿个 1 MB 文件更加高效和有效地利用资源。将所有数据移动到合适的数据库管理器（MySQL、SQL Server 等）中也可以实现这一点，并且可能提供其他好处，例如轻松搜索和简单的归档策略。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
