Apple's new Xcode® 3 is the most powerful Mac development suite ever created. In Xcode 3 Unleashed, renowned Mac developer Fritz Anderson has written the definitive guide to making the most of Xcode 3 to build any Macintosh® or iPhone® application.

This excerpt was provided with permission of Que Publishing,
a division of Pearson, from the book Xcode 3 Unleased.

Anderson leads you through a simple project that covers the entire Xcode 3.x development lifecycle. You'll walk through building and debugging command-line tools, creating Mac OS X user interfaces, modeling data, localizing languages, compiling applications, and much more. Along the way, he introduces each of Apple's remarkable development tools from the latest version of Interface Builder to Instruments — a powerful new tool for analyzing and optimizing your code.

Instruments

IN THIS CHAPTER

• Instruments: Performance and Resources in Time
• Using the Instruments Window
• Configuring Instruments
• Apple’s Templates and Instruments
• Custom Templates and Instruments

Instruments is a framework for software-monitoring tools called… instruments. (Capital I Instruments is the application, small i instruments are components of the Instru ments application.) The analogy (borrowed from Apple’s Garage Band audio editor) is to a multitrack tape deck. Instruments records activity on one or more tracks (one per instrument), building the data on a timeline like audio on a tape.

What Instruments Is

The focus on a timeline makes Instruments unique. We saw how MallocDebug collects allocation and deallocation events, and gathers them into statistical measures, organizing all the stack traces it found at those events into an aggregate call tree, from which you can learn how memory is used. It presents data as an end-of-run accumulation.

Shark, too, works by statistical aggregates. You run your application, Shark samples it, and in the end it presents you with profiling information that is a summary (although very detailed) of all the samples of the whole run. You can filter the samples and manipulate the call trees Shark reports, but the product is still a compilation over a period of time. There is a chart view, but it is still an aggregate, showing the shape of the call stack over time. You can examine stack traces to see what the processor was doing at the time (it can be tricky to select exactly the right one), but there is no way to relate the traces to what the application was doing.

Further, tools such as MallocDebug and Shark do one thing at a time. MallocDebug does heap memory. Shark does profiling (or malloc tracing, or processor events). If you want a different measure, run the application again under the supervision of a different tool. They allow no way to see what one measure means in relation to another.

Instruments is different. It is comprehensive. There are instruments for most ways you’d want to analyze your code, and Instruments runs them all at the same time. The results are laid out by time, in parallel. Did clicking the Compute button result in Core Data fetches? Or had the fetches already been done earlier? Did other disk activity eat up bandwidth? In the application? Elsewhere in the system? Is the application consuming too many file descriptors, and if so, when, and in response to what? You’re handing data off to another process (think Linrg, from the first iteration of Linear); how does the tool’s memory usage change in response to the handoff, and how does it relate to the use of file descriptors in both the tool and the master application?

Instruments can answer these questions. You can relate file descriptors to disk activity, and disk activity to Core Data events, with stack traces for every single one of these, because Instruments captures the data on a timeline, all in parallel, event by event. And, you can target different instruments on different applications (or even the system as a whole) at the same time.

Note Most of the power of Instruments lies in the analysis tools it provides after a recording is made, but don’t ignore the advantage it provides in showing program state dynamically: If you can’t see when memory consumption or file I/O begins and settles down (for instance), you won’t know when to stop the recording for analysis in the first place.

Running Instruments

In Chapter 19, we started Instruments from Xcode by selecting Run > Start with Performance Tool and selecting an Instruments template. At least as often, you’ll just launch the Instruments application from the /Developer/Applications directory.

When you start it, Instruments automatically opens a document (called a trace document) and displays a sheet offering you a choice of templates populated with instruments for common tasks (see Figure 26.1). You can find a complete list of the templates Apple provides in the section “The Templates” later in this chapter.

Figure 26.1  When you create a new trace document in Instruments, it shows you an empty document and a sheet for choosing among templates prepopulated with instruments for common tasks.

Next Page

1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11