Diagnosing Memory Management Issues

Duration

10 minutes

Goals

In this demonstration, we will examine an application and watch it's memory allocation to identify some potential improvements we can make in the code.

Requirements

If you'd like to run this demo yourself, then you will need to install the Xamarin Profiler. This will work best (for this example) on macOS since we are profiling a Xamarin.iOS application here. You must also have an MSDN Enterprise license to use the Xamarin Profiler.

Assets

The provided Exercise 1 folder contains a subfolder named Start with a pre-built Xamarin.iOS application we will use with the Xamarin Profiler.

Challenge

We will run the supplied starter application under the Xamarin Profiler to observe it's memory behavior. There are a few places where we can optimize the code to better utilize memory.

Our basic steps will be:

  1. Launch the XamDraw application in the Xamarin Profiler.
  2. Draw on the screen and take a snapshot.
  3. Examine the memory objects still in use.
  4. Identify objects which should be collected earlier.
  5. Make changes in code to release objects more quickly.
  6. Verify changes with Profiler.

Steps

Below are the step-by-step instructions to run the demonstration.

Launch the XamDraw application in the Xamarin Profiler

Let's start by running our application in the profiler.

  1. Open the Start/XamDraw.sln solution in Visual Studio for Mac.
  2. Build the solution and then use the Run > Start Profiling menu option to open it in the Xamarin.Profiler.
    3. Note: You will need to have the profiler installed, and you will need an MSDN Enterprise license to see that menu option.
  3. When the profile starts, select the Allocations profiling template.
  4. Once the app has launched in the iOS Simulator, take a snapshot by clicking the camera icon in the toolbar of the profiler. This will give us an "initial state" of the app.

Draw on the screen and take a snapshot

  1. Next, draw some lines on the app surface and then take another snapshot. Use the Option key to simulate two touches simultaneously.
  2. Each time we take a snapshot, the Profiler will force a GC first to cleanup memory. So what we see in the snapshot are objects which survived the collection.

Examine the memory objects still in use

  1. Switch to the Snapshots tab in the profiler window and examine the output. Make sure to check the "Only New Objects" checkbox in the sidebar. If the sidebar is not visible, just click the little box on the right side of the view tab set.

Identify objects which should be collected earlier

  1. Look for objects which should have been collected - e.g. things which we don't expect to see a lot of. Here are some examples which you might find in this app:
    • CGPath objects used to draw the lines.
    • UITouch objects which tracked the touch events.
    • UIImage objects which are used to render the output - there should only be one of these.
    • UIColor objects which tracked the color of each touch.
  2. Select one of the objects and switch to the References section in the sidebar. If you don't see any references, then this object is eligible for collection but was promoted to the next generation because it was held too long.
  3. We can verify this by switching back to the Summary tab and selecting Only Persistent Objects in the side bar so we only see "live" objects. Sort the objects by class and find the UIImage set - then take another snapshot (which forces a GC) and they should all go away.

Make changes in code to release objects more quickly

  1. Let's work on the UIImage set first. Select one of the UIImage instances and click on the Stack Trace button in the side bar.
  2. This tells us where the image is being allocated. Here we can see (if we go down the stack far enough), that it's in XamDrawViewController.Drawline.
  3. Close the profiler and switch back to the code. See if you can rework the code to get rid of the image earlier by calling Dispose on it.
  4. You can also get rid of the temporary CGPath objects in the same routine by wrapping the creation of the path in a using block.

Verify changes with Profiler

Build and re-run the application in the profiler and see if the objects are still present in your snapshots. You can check your code changes by looking at the Completed sample included in the Exercise 1 folder.

Summary

In this demonstration, you've seen how to utilize the Xamarin Profiler tool to diagnose Xamarin based applications. The same things we did here would be applicable to any profiler - so you could follow the same basic procedure using the Visual Studio profiler for example, or RedGate's ANTs profiler.

Go Back