Hi,
Whilst I cannot give you answers I have been profiling one of my apps recently
and noticed similar things going on, can you show us your code that you are
using, what I did find made a difference for me was scope, because the GC was
causing problems I declared almost everything at the class rather than
module/event level, I am slowly moving more of my declarations back to the
module/event level this has improved how well GC is working for me, I also
found that specifically using dispose on my objects or using () {} has also
helped, but there is still some bits hanging around but not much.
What you might find which is what I saw when profiling, was memory growing for
a while and every now and again going back down, this seemed to be not when GC
is being called so it , also memory never goes back to the base amount.
ATB
Alex
On 29 Oct 2012, at 08:07, "Randy Ficker" <[email protected]> wrote:
> I believe my MonoTouch app is leaking memory, and I’ve been struggling at
> figuring out why.
>
> By using Instruments I can see the allocated memory grow and grow over the
> life of the app, eventually causing the app to die after 10 minutes or so of
> general use on my 3GS.
>
> To help isolate the problem, I first picked a specific action in my app I can
> easily repeat – just opening a menu and closing it again, which shouldn’t
> leave any garbage behind as the code is well-contained. Using Instruments, I
> can see that just opening and closing this menu adds about 90KB of
> allocations each time. If I open and close it 11 times, I’ve added a
> megabyte to my app’s memory use.
>
> I first tried enabling SGen and then the reference counting extension.
> Neither configuration changed the memory allocated.
>
> I tried commenting out parts of the menu that I thought might be leaking
> (images, custom-draw views, etc.). Doing this did reduce the memory leakage,
> but even if I comment out all of the functionality (to the point where my
> menu came up blank) it was still leaking 40KB each time. So I still feel I’m
> missing something fundamental.
>
> I was concerned that the garbage collector might just not be running, flawing
> my test results. I added a call to GC.Collect() but that didn’t change
> anything. I also tried doing it 50 times in a row, leaking over 4 megs of
> memory, to see if the GC would eventually collect it all. It never did.
>
> Throughout this, I’ve been trying to understand the mono memory profiler.
> Following the instructions, I take a shot, open and close my app’s menu, and
> take another shot, then diff them, and I see this:
> http://i.imgur.com/N4Ngb.png. Checking “Roots only” doesn’t change anything
> (the three new columns are empty). Instruments->Leaks shows this:
> http://i.imgur.com/hbJQ1.png
>
> For comparison, I also ran the profiler against my code with virtually all of
> my code commented out (it was just bringing up a blank menu). Memory leak is
> about 40KB in this scenario: http://i.imgur.com/eIlK7.png
>
> I’m very confused by these results. My questions are:
>
> 1. What is <Other Root> and why does it have thousands of instances
> that total 0 memory? This appears to be the common factor in both of them.
> 2. In the first one, it says 20KB of strings leaked. How can I tell
> where these are coming from or why they aren’t being collected?
> 3. What uses System.WeakReference and why would it be leaking?
> 4. The mono profiler only seems to account for a small part of the
> total memory being leaked. Is there anything else I can try?
> 5. What else can I do to try and figure out why my app is continually
> growing in memory?
>
> I feel like I’m missing something fundamental here. I’d appreciate any
> advice anyone can offer!
>
>
> _______________________________________________
> MonoTouch mailing list
> [email protected]
> http://lists.ximian.com/mailman/listinfo/monotouch
_______________________________________________
MonoTouch mailing list
[email protected]
http://lists.ximian.com/mailman/listinfo/monotouch
