Tuning performance with Instruments

Application performance enhancement is always a risky business. It usually involves a lot of work to even start finding the bottlenecks. Luckily for us, we have Instruments. Instruments is a wonderful suite of test application that we can run over our own software, and it great to help us find weak spots.

So, lets begin with Time Profiler. Time Profiler inherits from Shark, a well known suite. Time Profiler is performed from within the kernel, meaning the impact on the application we are sampling is very low. It can also be used not just to look at the threads of the application, but also all threads, so we can find when we are waiting for other threads to get done.

There are two basic modes of recording modes:

• Immediate: the one used by default. It is really useful to correlate user events with profile. But because Instruments uses the same CPU that the app we try to snoop at, it also consume some of the time that otherwise could be used by the application. Apple calls this the Observer Effect.
• Deferred Mode: New in iOS 4. Here instruments disable your UI, the track and the detail views while you are recording, and it defers all of the data processing towards the end of the run. As you would expect, it minimizes the Observer Effect. To opt for this option, we need to enabled it from the file menu > Record Options

Time profiler looks at the threads open for the application, and simply takes samples at regular time intervals. With all this samples, Time Profiler builds what is called a Call Tree. A Call Tree is nothing more than a different way to show the stack, hopefully, one that is better suite to human brains. In particular, Instruments will show the stack as an outline, indicating where the threads spawn.

Instruments also offers a disassembly view, that shows the actual ARM or Intel code. This is useful when we have a couple of nested calls, and we see that the code is spending a lot of time within the boundaries of the nest. In the disassembly view we have the chance to see exactly what method is the one that is wasting all the time. Another cool thing to do with this view is to take a closer look at tight loops. There are two access points to the disassembly we. One is thought the info button in the source view, The other through the little icon on top of the source code panel with two squares. In the latter option, we will reach a panel that is also annotated, as the source code panel. In Instruments for Xcode 4, Apple also includes pointers to the ISA documentation.

So, with Time Profiler sampling the app once per .001 seconds, you will be really soon swimming in a huge see of frames from the stack. In fact, much of those frames are from the System, code we have no control over. How we can reduce the noise to information ratio? Well, there are a few things we can do.

• Charge symbols or Library to caller: Time Profiler will tally the time spent for a system symbol or even a complete library, to the method that calls it.
• Prune Symbol and subtree: So you are pretty sure that there is nothing in the world that can shave a millisecond from a given portion of your app? Then you can instruct Time Profiler not to display it. In this case, Time Profiler will remove the the symbol and the subtree associate with it (all the code called from the marked symbol) from the tally.
• Flatten Library to Boundaries: Let’s say that you call a Core Audio function, that itself spawn a lively arrange of calls to the stack. Again, you cannot do much about how Core Audio works internally, but you might find useful to instruct Time Profiler to show you just the boundaries between your code and Core Audio.