When to use .NET BufferedStream class?

The MSDN site states:

A buffer is a block of bytes in memory used to cache data, thereby reducing the number of calls to the operating system. Buffers improve read and write performance. A buffer can be used for either reading or writing, but never both simultaneously. The Read and Write methods of BufferedStream automatically maintain the buffer.

Should I use this class in every possible occasion?

Solution 1:

According to Brad Abrams, almost never: link

No, there is zero benefit from wrapping a BufferedStream around a FileStream. We copied BufferedStream’s buffering logic into FileStream about 4 years ago to encourage better default performance... In fact, I don’t think there are any Streams in the .NET Framework that require it, but it might be needed by custom Stream implementations if they do not do buffering by default.

Solution 2:

The following is some text from an online course I am taking:

The BufferedStream class is a concrete class that extends the Stream class and is used to provide an additional memory buffer to another type of stream, both synchronously and asynchronously. The BufferedStream class must be configured to either read or write when an instance of the class is created, but the BufferedStream cannot be configured to perform both the tasks at the same time.

Microsoft improved the performance of all streams in the .NET Framework by including a built-in buffer. The performance noticeably improved by applying a BufferedStream to existing streams, such as a FileStream or MemoryStream. Applying a BufferedStream to an existing .NET Framework stream results in a double buffer.

The most common application of the BufferedStream class is in custom stream classes that do not include a built-in buffer.

Solution 3:

Best case I know of is when BinaryFormatter serialize/deserialize directly from NetworkStream. Use of BufferedStream inbetween increase performance tenfold.