【问题标题】：Read whole file in memory VS read in chunks读取内存中的整个文件 VS 读取块
【发布时间】：2011-05-06 11:49:00
【问题描述】：

我对 C# 和编程比较陌生，所以请多多包涵。我正在开发一个应用程序，我需要读取一些文件并以块的形式处理这些文件（例如，数据以 48 字节的块处理）。

我想知道在性能方面，在内存中一次读取整个文件然后处理它，或者以块读取文件并直接处理它们，或者以更大的块（多个块然后处理的数据）。

到目前为止我是如何理解的：

读取内存中的整个文件
优点：
- 它很快，因为最耗时的操作是寻找，一旦磁头就位，它可以非常快地读取

缺点：
-它消耗大量内存
- 它在很短的时间内消耗大量内存（这是我主要害怕的，因为我不希望它显着影响整体系统性能）

分块读取文件
优点：
- 实现起来更容易（更直观）

while(numberOfBytes2Read > 0)
   read n bytes
   process read data

-它消耗很少的内存

缺点：
-可能需要更多时间，如果磁盘必须再次寻找文件并将磁头移动到适当的位置，平均花费大约 12 毫秒。

我知道答案取决于文件大小（和硬件）。我认为最好一次读取整个文件，但是对于文件的大小，建议一次在内存中读取的最大大小是多少（以字节为单位或相对于硬件 - 例如内存）？

感谢您的回答和时间。

【问题讨论】：

【解决方案1】：

建议读取 4K 或 8K 的缓冲区中的文件。

如果你想将文件写回另一个流，你真的不应该一次读取所有文件。。只需读取缓冲区并将缓冲区写回即可。这尤其适用于网络编程。

如果您必须加载整个文件，因为您的操作（文本处理等）需要文件的全部内容，缓冲并没有真正的帮助，所以我相信它是首选 File.ReadAllText 或 File.ReadAllBytes。

为什么是 4KB 或 8KB？

这更接近底层的 Windows 操作系统缓冲区。 NTFS 中的文件通常存储在磁盘上的 4KB 或 8KB 块中，尽管您可以选择 32KB 块

【讨论】：

为什么只有4-8K？如果您正在读取 1-100MB 的大文件，这不会导致大量读取（以及可能的新搜索和上下文切换）吗？更大（1-100MB）的缓冲区会对整个系统产生负面影响吗？假设我不会写它们到另一个流并且我不需要一次所有数据，这完全与性能有关。
这更接近底层的 Windows 操作系统缓冲区。 NTFS 中的文件通常存储在磁盘上的 4KB 或 8KB 块中，尽管您可以选择 32KB 块
@Ben 实际上，Windows（或其他操作系统）甚至您的硬盘驱动器本身都会进行另一层缓冲/缓存，因此更大的缓冲区可以和小的一样有效。只有非常小的缓冲区（小于集群大小）才会产生明显的负面影响。

【解决方案2】：

你的块需要足够大，48字节当然小，4K是合理的。

【讨论】：