[Mono-dev] Should we replace MemoryStream?

[Alan McGovern]

Hey,

On Mon, Nov 9, 2009 at 6:29 PM, Avery Pennarun <apenwarr at gmail.com> wrote:

> On Mon, Nov 9, 2009 at 1:10 PM, Miguel de Icaza <miguel at novell.com> wrote:
> >    I just blogged about a memory fragmentation issue here:
> >
> >        http://tirania.org/blog/archive/2009/Nov-09.html
> >
> >    And I am wondering: since MemoryStream is one of these sources of
> > problems, we could replace this implementation with MindTouch's
> > ChunkedStream.
>
> Probably stupid question: why is a compacting garbage collector
> actually needed?  C programs have survived for a *long* time without
> any ability whatsoever to compact memory, simply by carefully
> optimizing their allocation algorithms to avoid fragmentation.  Is the
> mono allocator very non-optimal in this respect?
>

One of the causes is that in a garbage collected language you allocate when
you need something and discard it when you're done. If you do this with
large buffers which are pinned in memory and have just the wrong allocation
pattern, you can bloat your memory usage. There's nothing mono can do in
this case as essentially it's the user causing the bloat.

One thing you can do is keep a cache of buffers yourself and re-use them.
For example if your application allocates 10 chunked memory streams a second
and Dispose () them when you're done, you could add/remove the 'chunks' from
a cache. This way you'd only ever allocate 10xsizeof (chunked stream) bytes
of memory and you'd constantly re-use them.

Alan.



> Like I said, I feel like this is a stupid question.  But I'm curious
> about the answer, and neither your blog post nor the linked page on
> the sgen collector addresses it.
>
> Thanks,
>
> Avery
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20091109/58b2d558/attachment.html