24

What is the difference between BufferedStream and MemoryStream in terms of application? Since MemoryStream can be flushed into a file at any time, couldn't it replace BufferedStream?

softwarematter
  • 28,015
  • 64
  • 169
  • 263

2 Answers2

39

BufferedStream is just a buffer over an existing stream. MemoryStream is a buffer for the whole stream - it isn't chained to another one. You can ask it to write itself to another stream at any time, but that's not the same thing.

One of the principle reasons for buffering is to avoid frequent writes to expensive resources. However, that doesn't mean you want to buffer all the data in memory - just enough to avoid very small writes. For example, if FileStream didn't have its own buffering strategy, then wrapping it in BufferedStream could end up with a buffer of only 8K even if you write megabytes of data. As pointed out in the comments though, FileStream has enough buffering that using BufferedStream in conjunction with it is pointless.

Glorfindel
  • 21,988
  • 13
  • 81
  • 109
Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • see for BufferedStream: http://msdn.microsoft.com/en-us/library/system.io.bufferedstream.aspx see for MemoryStream: http://msdn.microsoft.com/en-us/library/system.io.memorystream.aspx – Mark Synowiec Sep 17 '09 at 16:13
  • @Jon: FileStream already buffers (thus its Flush method). And I don't see any property on BufferedStream that would allow you to set the size of the buffer you want to create. So it seems to me BufferedStream would be unnecessary or redundant . . . is it just that BufferedStream inherently creates a larger buffer than FileStream and other Stream classes? – richard Jan 12 '11 at 20:35
  • @Richard: You can specify the buffer size in one of the constructor overloads for BufferedStream. – Jon Skeet Jan 12 '11 at 20:36
  • @Jon: Is that its only benefit over FileStream's buffering? – richard Jan 12 '11 at 21:00
  • @Richard: Not sure, to be honest. It would depend on exactly how the buffering worked internally. – Jon Skeet Jan 12 '11 at 21:02
  • 1
    @Jon: Ok, I don't mean to beat a dead horse here, but how/why would you use the BufferedStream then? Just as a matter of good practice when a buffer needs to work reliably as we want it to (i.e. by specifiying its size)? – richard Jan 12 '11 at 21:04
  • @Richard: I can't remember using it myself, to be honest. I don't know whether `NetworkStream` is similarly buffered - possibly buffering that if you were doing lots of small reads/writes would be helpful. Or a compression stream, maybe? Although I'd expect that to have its own buffer too... – Jon Skeet Jan 12 '11 at 21:14
  • 2
    There is no benefit in using BufferedStream and FileStream together. See http://blogs.msdn.com/b/brada/archive/2004/04/15/114329.aspx. It would appear from my experimentation that IsolatedStorageFileStream does not include any buffering (at least on Silverlight on Windows Phone 7), so could potentially benefit from BufferedStream. Unfortunately Silverlight doesn't have a BufferedStream implementation. – 1adam12 Jul 17 '11 at 23:19
  • wrt to NetworkStream: afaik the TCP stack offers some buffering already. This will reduce the number of calls from the system to the kernel. I am not sure what gains you can get from adding another layer of buffering. It will reduce the number of calls to winsock2. I guess this could help. However all of this would add a bit of latency. What do you guys think? – uriDium May 02 '13 at 08:12
  • @uriDium: I think you'd need to test it in real world scenarios to find out what's relevant to your actual app. – Jon Skeet May 02 '13 at 08:27
7

BufferedStream must be initialized by some other existing Stream. A simple close triggers the flush of the buffer to the underlying stream. It's needed when working with a non-memory stream but you need (auto)-buffering.

MemoryStream can exist on its own, but also can be flushed to other streams as you said but 'explicitly'.

If your work is only on memory, it's better to use MemoryStream. Otherwise, BufferedStream.

manji
  • 47,442
  • 5
  • 96
  • 103