我正在编写一个小型的I/O库，以协助完成一个更大（业余）项目。该库的一部分通过FileStream对象读取/写入文件，并执行各种操作。在每个StreamReader.Read(...)调用时，我会触发一个事件，用于在主应用程序中显示进度信息。循环中进行的处理是多样化的，但时间消耗不太大（例如可以只是简单的文件复制，或者可能涉及加密...）。
我的主要问题是：使用哪种最佳内存缓冲区大小？考虑到物理磁盘布局，我可以选择2k，这将覆盖CD扇区大小，并且是512字节硬盘扇区的好倍数。在更高的抽象层次上，您可以选择更大的缓冲区，它可以一次读取整个FAT簇。我意识到在今天的PC上，我可以选择更耗费内存的选项（例如几MiB），但这会增加UI更新之间的时间，并导致用户感知到一个反应较慢的应用程序。
另外，我最终希望为托管在FTP / HTTP服务器上的文件提供类似的接口（通过本地网络/较快的DSL）。对于那些文件，什么是最佳的内存缓冲区大小（再次是“最佳情况”下感知响应速度和性能之间的权衡）?
文件已经被文件系统缓存了。你只需要选择一个缓冲区大小，不要过于频繁地强制FileStream调用本地Windows ReadFile() API来填充缓冲区。不要低于1KB，超过16KB会浪费内存并对CPU的L1缓存（通常为16或32KB的数据）不友好。
4KB是一种传统的选择，尽管这只会偶然地跨越一个虚拟内存页。很难进行分析；你最终会测量读取缓存文件需要多长时间。如果数据在缓存中可用，则运行速度为RAM速度，每秒5GB及以上。第二次运行您的测试时，它将在缓存中，而在生产环境中不会经常发生。文件I/O完全受到磁盘驱动器或NIC的支配，并且速度非常慢，复制数据则很快。4KB的缓冲区大小可以很好地工作。
_DefaultCopyBufferSize的值为0x14000（81920或80K）。但是，这仅适用于从流复制到另一个流时的缓冲区大小，并非数据缓冲区。BufferedStream类的_DefaultBufferSize为0x1000（4096或4k），这将更好地了解.NET框架用于流的缓冲区大小。 - Owain WilliamsFileStream 时，如果要获得最佳的异步性能，缓冲区大小应至少为1兆字节，以便在等待重叠磁盘IO完成时异步开销的成本值得。我不记得从哪里得到这个细节，但你同意吗？ - Dai当我直接通过流对象处理文件时，我通常使用4096字节。在多个I/O领域（本地文件系统、LAN/SMB、网络流等）中似乎相当有效，但我没有对其进行剖析或其他操作。很久以前，我看到过几个示例使用这个大小，它就一直留在我的记忆中。但这并不意味着它是最好的。
"这取决于。"
你需要使用不同的缓冲区大小来测试你的应用程序，以确定哪个是最好的。你不能提前猜测。
我认为默认值通常是最好的选择 - 因此我在FileStream类中使用4096B，它基于internal const int变量DefaultBufferSize。