[Mono-dev] Should we replace MemoryStream?

[Avery Pennarun]

On Tue, Nov 10, 2009 at 8:48 AM, Robert Jordan <robertj at gmx.net> wrote:
> MemoryStream.GetBuffer's docs indirectly suggest that no copy
> will be performed:
>
> "Note that the buffer contains allocated bytes which might be unused.
> For example, if the string "test" is written into the MemoryStream
> object, the length of the buffer returned from GetBuffer is 256, not 4,
> with 252 bytes unused. To obtain only the data in the buffer, use the
> ToArray method; however, ToArray creates a copy of the data in memory."
>
> So MemoryStream.GetBuffer must remain an O(1) operation in any case,
> defeating any kind of optimization a chunked memory stream
> implementation may introduce.

Although this might be strictly true if you want to react exactly as
Microsoft's documentation claims (I thought 100% compatibility with
.Net was not the primary goal of mono?), there may be other options
that result in similar performance

For example, the first call to GetBuffer() could "coagulate" the
chunks into a single big array (perhaps with extra space at the end),
and then *keep that array*.  Subsequent calls to GetBuffer() could
avoid the copy.

In the event that your initial chunk wasn't big enough when pushing
data into the buffer in the first place, a non-chunked implementation
would have had to make an extra copy *anyway* at the time of the push.
 So in the chunked implementation, the extra copy on the first
GetBuffer() is actually not an *extra* copy at all vs. the naive
single-buffer implementation.

(I've written an efficient implementation of chunked buffering in C++,
and these were the conclusions I drew after a lot of benchmarking of
my library.  YMMV in C#, etc.)

Have fun,

Avery