相关疑难解决方法(0)

我正在编写一个小型I/O库来协助更大的(业余爱好)项目.该库的一部分对文件执行各种功能,该文件通过FileStream对象读/写.每次StreamReader.Read(...)通过时,

我将启动一个事件,该事件将在主应用程序中用于显示进度信息.在循环中进行的处理是有缺陷的,但不是太耗时(例如,它可能只是一个简单的文件副本,或者可能涉及加密...).

我的主要问题是:使用的最佳内存缓冲区大小是多少？考虑到物理磁盘布局,我可以选择2k,这将覆盖CD扇区大小,并且是512字节硬盘扇区的很好的倍数.在抽象树的上方,你可以选择一个更大的缓冲区,它可以一次读取整个FAT簇.我意识到今天的PC,我可以选择更多的内存饥饿选项(例如几个MiB),但随后我增加了UI更新之间的时间,并且用户感觉到响应速度较慢的应用程序.

顺便说一句,我最终希望为FTP/HTTP服务器上托管的文件提供类似的界面(通过本地网络/快速DSL).那些最佳的内存缓冲区大小(再次,感知响应性与性能之间的"最佳情况"权衡)？

我正在阅读二进制文件,这是一个示例:

public static byte[] ReadFully(Stream input)
{
    byte[] buffer = new byte[16*1024];
    int read;
    while ((read = input.Read(buffer, 0, buffer.Length)) > 0)
    {
        ......
    }

}

显然缓冲区大小(16*1024)在性能方面有很大的作用.我读过它取决于I/O技术(SATA,SSD,SCSI)等)以及它上面存在文件的分区的片段大小(我们可以在格式化分区期间定义).

但问题是: 是否有任何公式或最佳实践来定义缓冲区大小？现在,我正在根据反复试验来定义.

编辑: 我已经在我的服务器上测试了不同缓冲区大小的应用程序,并且我获得了4095*256*16(16 MB)的最佳性能!4096慢了4秒.

以下是一些非常有用的旧帖子,但我仍然无法得到原因:

• .NET中更快(不安全)的BinaryReader

• 最佳文件缓冲区读取大小？

• 带流的文件I/O - 最佳内存缓冲区大小

• 使用FileInputStream时如何确定理想的缓冲区大小？