[MonoTouch] Experimental reference counting - any progress?

[Rodrigo Kumpera]

On Wed, Mar 21, 2012 at 5:11 PM, René Ruppert
<rene.ruppert at googlemail.com>wrote:

> Hi Rodrigo,****
>
> ** **
>
> That’s good news to hear that you are constantly improving memory
> management.****
>
> ** **
>
> Would you mind answering/commenting on a few topics related to memory
> management?****
>
> ** **
>
> Is it „normal“ for Monotouch applications to have an ever growing memory
> footprint and (according to Instruments) never seem to drop back to the
> initial value, even after a forced GC? Is this effect due to fragmentation
> of the heap (I guess even SGen cannot prevent fragmentation 100%)?****
>
> **
>

This the the expected behavior most of the time. A garbage collection does
not release all memory after a collection as it's expected to be used
shortly after and doing so would have a significant performance cost. What
happens is that it does shrink the heap if too much memory becomes
available.



> What I’m also still wondering about: starting a Monotouch app shows
> initially 20MB of memory allocated in Instruments and pushing around a view
> UIViewControllers makes it grow to 30MB pretty quickly. An ObjC app only
> requires about 1MB. As there is not JIT runtime involved in Monotouch, what
> else requires so much memory compared to ObjC? Or is Instruments just wrong
> (but at least it’s relatively easy to get memory warnings, so it cannot be
> all wrong)?
>

A Monotouch app require to load the mono runtime, create a managed heap and
load runtime metadata. Are those numbers with release or debug builds?
Debug builds have a much bigger footprint since nothing is stripped out.

The number for objc are that much smaller because most of the footprint is
hidden behind memory sharing with other processes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/monotouch/attachments/20120321/778d7bf1/attachment-0001.html>