C# 在内存中读取整个文件与在块中读取

我对C#和编程还比较陌生，所以请耐心听我说。我正在使用一个应用程序，在这个应用程序中，我需要读取一些文件，并以块的形式处理这些文件（例如，数据以48字节的块进行处理）

我想知道，在性能方面，一次在内存中读取整个文件，然后对其进行处理，或者分块读取文件，然后直接对其进行处理，或者分块读取更大的数据（然后处理多个数据块），哪种方法更好

到目前为止我对事物的理解：

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

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

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

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

-它消耗很少的内存

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

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

---

感谢您的回答和时间。

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

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

如果由于您的操作（文本处理等）需要文件的全部内容，因此必须加载整个文件，缓冲并没有真正的帮助，因此我认为最好使用

file.ReadAllText

或

file.ReadAllBytes

---

为什么是4KB还是8KB？

---

这更接近底层Windows操作系统缓冲区。NTFS中的文件通常存储在磁盘上的4KB或8KB chuncks中，尽管您可以选择32KB chuncks，但您的数据块需要大一点，48字节当然是小一点，4K是合理的。

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