Memoryleak hunting in monotouch and mvvmcross using profiller tool

Question

I have been working to eliminate memory leaks in our mono touch and learned a lot in last couple of days e.g. that it is almost always some event that needs to be unhook before garbage collecting is succeeded :)

But now I have been playing around with the profiller tool and I can see that most of the memory is used by strings (or it seems), please see the following screendump:

But as you can see some memory is also used by mono. I have been working our viewmodels and views and most of these are garbage collected correct. If I look into the strings they sometimes are referenced by and I have no clue what to do with this info. Do you guys have any suggestion if I can reduce the amount of memory used by strings :) I have tried to find any tutorial or similar that might enlight what these numbers means, but with no luck. Any help is appreciated.

Answer 1

Some answers from my personal experience:

• For tutorial I only really know about http://docs.xamarin.com/ios/Guides/Deployment%252c_Testing%252c_and_Metrics/Monotouch_Profiler

• I find the 'Inverse References' option one of the most useful features - what matter is not that you have a lot of strings, but rather what owns those strings.

• I find the best way of hunting these bugs is to reproduce them in a simple test harness and/or test sequence - as apps get bigger and I use more and more components - MvvmCross, JSON.Net, SQLite-net, etc - in more and more asynchronous ways, then I find I need to cut down on the number of these components to identify the leaks.

• Once you have a simple test harness, the filter option in the HeapShot helps - as it lets you focus on classes which are in known namespaces.

• Once you have a simple test harness, then comparing two HeapShot's can also help - which actions in your test UI cause what increases between HeapShots?

  Differences are what matter - some libraries deliberately cache things in memory - e.g. some of the PropertyInfo's in your HeapShot images might be deliberately cached by one of the libraries in order to improve deserialisation speed.

---

For easier cross-referencing, adding links to linked questions:

• Garbage collecting issue with Custom viewbinding in mono touch and mvvmcross
• when to release objects in mono touch / mvvmcross
• MVVMCross - SqlBits Memory Leak
• Helping the GC in mono droid using mvvmCross

Answer 2

In addition to Stuart's great answer, I'd like to stress that you should profile on device. Execution on device is tweaked for runtime performance, while the simulator is tweaked for build performance (so that the edit-debug cycle is as fast as possible). Among other things it means that in the simulator more memory is used at runtime than in on device.