[Mono-dev] Should we replace MemoryStream?

[Andreas Nahr]

I'm still not sure this is a good idea. A lot of this depends on the
use-case for MemoryStream.
If 
1) A MemoryStream is created with a parameterless constructor and then a lot
of data written to it multiple times the ChunkedStream will be better
always.
2) If a MemoryStream is created with a parameterless constructor and only
gets a few bytes long ChunkedStream might bring considerable overhead.
3) If MemoryStream is created with a fixed size then ChunkedStream will be
somewhat, but acceptably slower and have a higher overhead. But it will be
totally abysmal once GetBuffer comes into play.
4) If MemoryStream is constructed from a (large) byte array (in the
scientific field I'm coming from this is by far the most common usage I've
seem; that is basically using MemoryStream as a (read-only) Stream-Wrapper
around a byte array) then performance will be abysmal when constructing (if
you chunkify e.g. a 500MB byte array) AND again with GetBuffer (recreate the
array). So would be O (n) or even O (2*n) instead of O (0).

It might be possible to create an implementation that can deal with all this
(would need to have variable sized buffers, keep things it gets passed in
the constructor alive with small overhead, etc.), but it will be quite
complex and come with a large base overhead. And even then the GetBuffer
O(n) problem remains in a few scenarios.

Maybe it would be better to just leave the class as is and document that for
certain scenarios alternative implementations are available that do a MUCH
better job. Everybody can easily replace the use of MemoryStream with an
alternative implementation if needed. But nobody expects this class to
behave completely different from how it originally did (and seems to do in
MS.Net).

Andreas