我正在接收一个文件，作为byte []数据包流（总大小未知），需要在接收到该文件之前将其存储在某个地方，然后立即对其进行处理（我无法即时进行处理） ）。接收到的文件总大小可以从10 KB到4 GB以上不等。
MemoryStream，即一系列MemoryStream.Write(bufferReceived, 0, count)调用来存储接收到的数据包。这非常简单，但是显然会导致大文件的内存不足异常。FileStream，即FileStream.Write(bufferReceived, 0, count)。这样，不会发生内存不足异常，但是我不确定是由于磁盘写入而导致的性能下降（只要有足够的可用内存，我就不想发生这种情况）-我想尽可能避免磁盘访问，但是我不知道控制它的方法。我进行了一些测试，并且在大多数情况下，MemoryStream.Write()vs的10000次连续调用之间似乎没有什么性能差异FileStream.Write()，但很大程度上取决于缓冲区大小和所讨论的数据总量（即写入次数） 。显然，MemoryStream大小重新分配也是一个因素。
是否有意义使用的组合MemoryStream，并FileStream在默认情况下，即写入内存流，但一旦接收到的数据总量超过例如500 MB，写入到FileStream; 然后，从两个流中读取大块以处理接收到的数据（首先从中处理500 MB MemoryStream，将其处理，然后从中读取FileStream）？
另一种解决方案是使用自定义内存流实现，该实现不需要连续的地址空间来进行内部数组分配（即，内存流的链表）。这样，至少在64位环境中，内存不足异常不再是问题。缺点：额外的工作，更多的错误余地。
因此，在磁盘访问和内存缓存（即数据大小/性能平衡）方面，FileStreamvsMemoryStream读写行为如何。我希望只要有足够的RAM可用，FileStream无论如何都会从内存（缓存）内部进行读写，而虚拟内存将负责其余的工作。但是我不知道FileStream写入时会显式访问磁盘的频率。
任何帮助，将不胜感激。
不，尝试对此进行优化没有任何意义。Windows本身已经缓存了文件写入，它们由文件系统缓存来缓冲。因此，您的测试是准确的，MemoryStream.Write（）和FileStream.Write（）都实际写入RAM，并且在性能方面没有显着差异。文件系统驱动程序懒惰地将其写入后台磁盘。
用于文件系统缓存的RAM是在进程声明其RAM需求后剩余的空间。通过使用MemoryStream，您会降低文件系统缓存的效率。换句话说，您将一项交易换为另一项却没有收益。实际上，您的情况更糟，您使用的RAM量是原来的两倍。
不用帮助，这已经在操作系统内部进行了优化。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句