Information Technology Reference
In-Depth Information
configuration under the Instruments list. The initial 10 second default is excessively long for many applications. As
apps use more memory, the performance hit becomes more obvious, so use this feature with care.
Generally, the time line is best used for quick broad-brush overviews of app activity. It's not a precise diagnostic
tool, but it does give you enough information to check whether more detailed investigation is necessary.
Getting started with the statistics
The statistics in the detail pane are the key to using Instruments productively. Where the time line provides an
overview, the statistics provide extremely detailed information.
At first sight, the Allocations statistics may look complex, but the display is simply a list of all objects created by
your app, with an associated instance count, and the instrument is literally monitoring and counting every ob-
ject in memory.
A combined All Allocations summary at the top of the list counts the total number of objects and lists the total
memory used. You can click each column header (Category, Live Bytes, # Living, and so on) to sort the list in
various ways and to highlight aspects of the data.
NOTE
If you can't see the display shown in Figure 16.11, select the Allocations instrument at the top left of the time line
pane and select Statistics and Object Summary using the menus under the time line.
NOTE
Allocations displays all objects and all low-level memory allocations. Many of the objects in the list aren't docu-
mented, because they are internal to the OS and are created and released at a low level. Typically, when you cre-
ate a standard Cocoa object, the allocation code runs a number of low-level allocations and creates various other
low-level structures and objects. Allocations lists them all separately.
As the app runs, you see that both the # Living and the # Overall counts for the All Allocations summary in-
crease by one every second. The # Living column counts objects that are allocated and active. The # Overall
column is a running total for the app, and it includes objects that have been released. Because our leaky app
doesn't release any objects, the two numbers are identical. In a real project, the two numbers diverge almost im-
mediately.
CAUTION
Occasionally, you find that Apple's own iOS and OS X objects are leaking memory. When this happens, Instru-
ments shows it clearly. But don't forget that in the application, the objects are organized in a hierarchy and not a
linear list, and OS objects may leak memory at the
malloc
level. If your code is doing nothing while memory al-
locations are increasing, you're likely dealing with a genuine OS bug. You may not be able to see which object is
causing the problem, because Allocations is reporting the problem as a low-level leak.
Monitoring specific objects
