Inspecting Performance with Instruments

We’ve looked at a few places where you can make an app faster, but what about the rest of the time? How can you make a method return faster if you don’t know where it’s slow? You can guess, looking at the code with your brow furrowed until you decide to change something, but that’s problematic. Not only could you be ignoring non-obvious performance problems, but in your attempt to fix the issue, you could actually make it slower!

What you need is data, and that’s where Instruments, a performance-analysis and testing tool bundled with Xcode, comes in. Let’s try it out.

In Xcode, open TapALap and select Product → Profile or press ⌘I. This builds your app in its Release configuration, which performs additional optimizations and is closer to what the final product in the App Store will be. It’s important to perform those optimizations before profiling the code; otherwise, you might end up improving code that will be optimized anyway. Once the app is built, Instruments is launched and asks you to select an instrument from an array of profiling templates, shown in the following figure.

What you want is Time Profiler. Select that, and click Choose.

The window that appears next looks like a video editing interface. This is the main Instruments window and will display the processing in your app over time. Other instruments show things like memory allocation, memory leaks, and graphics processing over time. Time Profiler helps you understand where your code is taking the longest to run. First, you need to run the app. Click the red record button in the toolbar, and the app will launch. You’ll see the app start in the simulator, but you’ll also see data start coming in about the app’s performance. After the app’s startup process has finished and new data stops coming in, you can click the Stop button to quit the app. Now you can analyze the data that came in.

Since you’re interested only in your own code, there are some boxes you can check to make navigation easier. Click the gear icon on the right-hand side or press ⌘2 to open Display Settings. Check Invert Call Tree and Hide System Libraries, and uncheck Separate By Thread. This will rearrange the code to be a bit friendlier to go through. Expanding the first element in the list will show you the longest running piece of code, shown here:

The real power of Instruments comes when you select the first element in the list and double-click it. The screen changes from the list of method calls to your code, annotated with how slow each individual line is. As you can see in the screenshot, three of the lines of code in the lower-left section have shaded backgrounds that correspond to how much time is spent on those particular lines. According to the data, we’re spending a lot of time using distance formatters and duration formatters.

With this data in hand, you can run your app in Instruments, examine where it’s slow, and try to fix it. In this case, you might try to cache the result of the distance and duration formatters to make it faster. The important thing about Instruments, however, is that you get real data out of it. Instead of poking around blindly, you can make actionable decisions about your code and see real results.

Time Profiler is but one of many amazing tools available in Instruments. You can use the Allocations instrument to view the history of every object allocated by your app, from creation to destruction. Use the Leaks instrument to analyze memory leaks and pinpoint the objects that are sticking around. You can even create custom instruments. If you want to track memory leaks while also using Time Profiler, it’s as easy as dragging tools out of a library. For more information on Instruments, a great place to start is Apple’s WWDC videos.^[11]

Sometimes things are unavoidably slow, no matter how good your code is—such as loading things from the network on a slow hotel Wi-Fi connection. In those cases, how can you make your app fast? Let’s look at one more technique: preloading data.