[Mono-dev] Should we replace MemoryStream?

pablosantosluac at terra.es pablosantosluac at terra.es
Tue Nov 10 07:09:03 EST 2009


I agree (especially thinking about the chunk-pool I mentioned) having
separate classes can be better, so that everyone can choose.

Andreas Nahr wrote:
> 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
> 
> 


More information about the Mono-devel-list mailing list