On Wed, Mar 21, 2012 at 5:11 PM, René Ruppert <[email protected]>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.
_______________________________________________ MonoTouch mailing list [email protected] http://lists.ximian.com/mailman/listinfo/monotouch
