.NET 二进制文件读取性能答案

【问题标题】：.NET Binary File Read Performance.NET 二进制文件读取性能
【发布时间】：2011-03-31 18:03:00
【问题描述】：

我有一组非常大的二进制文件，其中有几千个原始视频帧被顺序读取和处理，我现在正在寻求优化它，因为它似乎比 I/O 更受 CPU 限制.

目前正在以这种方式读取帧，我怀疑这是最大的罪魁祸首：

private byte[] frameBuf;  
BinaryReader binRead = new BinaryReader(FS);

// Initialize a new buffer of sizeof(frame)  
frameBuf = new byte[VARIABLE_BUFFER_SIZE];  
//Read sizeof(frame) bytes from the file  
frameBuf = binRead.ReadBytes(VARIABLE_BUFFER_SIZE);

在 .NET 中重新组织 I/O 以避免在每个帧中创建所有这些新的字节数组是否会有很大的不同？

由于我来自纯 C/C++ 背景，我对 .NET 的内存分配机制的理解很薄弱。我的想法是重写它以共享一个静态缓冲区类，该类包含一个非常大的共享缓冲区，其中一个整数跟踪帧的实际大小，但我喜欢当前实现的简单性和可读性，如果CLR 已经以某种我不知道的方式处理了这个问题。

任何意见将不胜感激。

【问题讨论】：

您是否运行了分析器以确保性能影响不是来自其他来源？还是您只是假设“大概就是这样”？
嗨大卫，我在它上面运行了几次性能分析器，这种特殊的方法是我最昂贵的方法。因此，我正在寻找这种“新字节 []”方法是否是 .NET 中明显的性能杀手。作为 C 程序员，这看起来类似于每个缓冲区的数千个“malloc”语句，这肯定会比重复使用的缓冲区慢。

标签： c# .net performance file binary

【解决方案1】：

如果你使用binRead.ReadBytes，你不需要初始化frameBuf——你会得到一个新的字节数组，它会覆盖你刚刚创建的那个。不过，这确实会为每次读取创建一个新数组。

如果您想避免创建一堆字节数组，您可以使用binRead.Read，它将字节放入您提供给它的数组中。但是，如果其他线程正在使用该数组，他们会看到它的内容就在他们面前发生了变化。确保您可以保证在重用缓冲区之前使用完缓冲区。

【讨论】：

感谢您指出这一点——我确信我的冗余分配会明显减慢这一速度。静态共享数组正是我正在考虑的，但是如果与创建字节数组相比性能增益并不大，我宁愿坚持使用优雅的解决方案来解决您概述的相同复杂性（共享访问） .

【解决方案2】：

您需要在这里小心。在这样的代码上很容易得到完全伪造的测试结果，在实际使用中永远不会重现的结果。问题是文件系统缓存，它将缓存您从文件中读取的数据。当您一遍又一遍地运行测试、调整代码并寻求改进时，麻烦就开始了。

第二次及以后运行测试时，数据不再从磁盘中取出。它仍然存在于缓存中，只需进行内存到内存的复制即可将其放入您的程序中。这非常快，一微秒左右的开销加上复制所需的时间。它以总线速度运行，在现代机器上至少每秒 5 GB。

您的测试现在将显示您在分配缓冲区和处理数据上花费了大量时间，相对于读取数据所花费的时间。

这在实际使用中很少会重现。数据还不会在缓存中，现在缓慢的磁盘驱动器需要寻找数据（很多毫秒）并且需要从磁盘盘片中读取数据（最多每秒几十兆字节）。现在读取数据需要四分之三的时间。如果您设法使处理步骤的速度提高一倍，您的程序实际上只会快 0.05%。给予或接受。

【讨论】：

这是一个很好的观点，但是我正在一个数据集上运行我的测试，该数据集使我的机器内存相形见绌几个 GB。我担心的是，我的旧 C++ 库中的类似代码将在不到一半的时间内处理这个数据集。但是，我确实注意到配置文件警告说，每秒大约有 2,826 页被写入磁盘，并且该应用程序可能受内存限制。我没有明确处理这些数组中的任何一个 - 这些数组是否会在 GC 取消分配它们之前被缓存？
这些缓冲区可能很大，超过 85KB。这让他们在 LOH 中分配。他们会被困在那里一段时间，这需要一个 gen#2 集合。没有什么是免费的，当缓冲区很大时重用缓冲区也是 .NET 中的一个好策略。
如果要强制从磁盘加载文件，请清除 Windows 文件缓存，如以下问题所示：stackoverflow.com/q/478340/80525