>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. But iOS memory warnings are issued if that total block of memory allocated through the app grows too much, even though the runtime only uses part of it, correct? This means that latest if the memory warning is fired, the amount of allocated memory should drop significantly, because then GC should really try to release as much as possible. If that does not happen, do I have to assume, that my app has leaked (lots of) memory, that cannot be reclaimed by GC/iOS, or could it be that now the fragmentation hits my app? Does SGen actually defragment? Im asking because I can sometimes see that the allocated memory (according to Instruments) grows to some value around 200MB, then the memory warning is received but memory usage wont drop. Eventually, the app crashes. Memory increases because of heavy use of web services. Im not holding any references. I will still have a closer look with the memory profiler but first I would like to understand the limitations of the GC to avoid hunting ghosts that I cannot kill. Ø 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. The numbers are lower with release builds. Compared to debug builds. René
_______________________________________________ MonoTouch mailing list [email protected] http://lists.ximian.com/mailman/listinfo/monotouch
