Find abandoned memory

The Allocations profiling template uses the Allocations and VM Tracker instruments to measure general and virtual memory usage in your app. However, to track down abandoned memory that’s been allocated but isn’t needed again, focus strictly on the Allocations instrument. This instrument measures heap memory usage and tracks allocations, including specific object allocations by class.

Launch Instruments.

In the profiling template selection dialog that appears, click Allocations.

Choose your device and app from the target device and process lists.

Click Choose to create a trace document.

Click the Allocations instrument in the timeline pane.

The Mark Generations button appears in the filter and configuration bar at the bottom of the detail pane.

Click the Record button () in the toolbar (or press Command-R) to begin recording.

Perform a short sequence of repeatable actions in your app.

In order to accurately generate trends, this should be a set of actions that starts and finishes with the app in the same state.

Click the Mark Generation button in the filter and configuration bar.

A flag appears in the track pane to identify the generation.

A list of generations you’ve marked is shown in the detail pane. Each generation includes a list of allocations that has occurred since the previous generation.

You can also mark generations after you’re done recording by dragging the inspection head in the track pane’s timeline to the desired location and clicking Mark Generation.

Perform steps 8 and 9 several times while monitoring the detail pane until you see whether memory is growing without limit.

Important: During the first few iterations, extra allocations may occur due to caching. Therefore, it is important to create a few initial generations for the purpose of establishing a baseline. Then, create additional generations for true analysis.

Click the Stop button () in the toolbar (or press Command-R again) when you’re ready to stop recording.

Scan through the generations in the detail pane and find one that seems representative of repeated memory growth.

The Growth and # Persistent columns tell you how much additional memory and how many allocations have occurred since the previous generation. If your app returns to its original state after an operation, you shouldn’t expect there to be growth from generation to generation.

Click the disclosure triangle () of a generation to display new objects that have been allocated since the prior generation.

Look for objects that are persisting. If you identify one, click the disclosure triangle () to display its instances.

Select an object instance.

Press Command-3 to display a stack trace for the selected instance in the extended detail area of the inspector.

This stack trace provides the complete list of method calls responsible allocating the instance.

Click the Collapse button () in the extended detail area to hide system calls in the stack trace. This makes it easier to locate your app’s methods.

Calls made by your app are colored black and preceded by a user code icon ().

Control-click on an entry in the detail pane, in the popover that appears choose Reveal in Xcode to show the source in Xcode.

Screenshot showing the popover for opening the user symbol in Xcode

Determine whether the allocation is useful. If it’s not, it’s abandoned memory that needs to be resolved.

Because abandoned memory is still referenced by your app, Instruments can’t determine its importance. To find abandoned memory, use generational analysis to ensure that memory does not continue to grow while repeatedly performing the same set of operations. For example, ending and starting a new game, opening and closing a window, creating and deleting a contact, or setting and unsetting a preference are all operations that should conceptually return your app to a previous and stable memory state. Extensive cycling through such operations many times should not result in unexpected or unrestrained memory growth. Instruments helps you correlate periods of memory growth with specific object allocations, so you can release them and reduce your app’s memory footprint.