我需要读取和处理超过1亿个文件，但是我只需要读取每个文件头的前4个字节，因为我只需要读取标题即可。
我已经创建了一个.net core 2.2批处理文件，并且已经使用多线程来最大化并发处理，但是在我想到所有可能的优化之后，它仍然花费太多时间。
我进行了基准测试，并且有78％的时间用于打开文件流：File.OpenRead（filePath）。
为了进行比较，File.Exist（filePath）和Director.Exist（dirPath）更快。
即使是我期望非常慢的函数Directory.GetFiles（dirPath），它也仅占用全局执行时间的4％。
另外15％的时间用于有效地从流中读取数据。
我从文档中了解到，默认缓冲区大小为4096字节，因此首先尝试减小为4字节，但是性能没有明显变化，但是我认为保留4096是正确的，因为这是群集的集群大小。文件系统。
该卷是使用CIFS协议访问的网络驱动器，但是文件保存在几个物理磁盘上。
为什么只打开流这么慢？也许是因为它需要检查用户权限？
您能建议一种访问所有文件的最快方法吗？
我认为现在是我的多任务免责声明的时候了：
运行循环遍历文件的一个替代任务非常标准。如果没什么，就是不要锁定主/ GUI线程。
但是以多种形式进行的多任务处理并不是神奇的“使事情更快”的项目符号。如果将其应用于错误的问题，最终将导致代码变得更复杂/更容易出错，对内存的要求更高，最重要的是，慢然后是简单的顺序代码。
现在，文件处理通常是磁盘或网络绑定的操作。您只能得到4个字节，所以我想您没有为每个文件执行很多自定义CPU工作。因此，这里唯一的CPU工作就是手柄的打开和关闭。我敢肯定，除非您为磁盘/网络使用一些antique like PIO，否则几乎没有什么。磁盘/网络也是如此。
在互联网上存在一些边缘情况，每个连接的限制，但我怀疑它们在这里是否适用。通常，每个文件的多任务处理并不能加快速度。
,FileStream比其他API（例如File.Exist，Directory.GetFiles等）要慢，因为它执行了大量SMB调用以标准化路径，要求权限等
您可以在Why is .NET's File.Open with a UNC path making excessive SMB calls?
那里得到更好的答案因此，加快流传输速度的最佳方法是直接调用本机API，从而避免了大多数控件的使用。
我发现这个很好的库可以很好地工作：https://github.com/i-e-b/tinyQuickIO
该库的唯一问题是它不针对.NET Core或.NET标准，但是如果您在Windows下使用它，它将起作用。