Tuning for Speed - iOS Core Animation - page 256

Test Reality, Not a Simulation
When you start doing any sort of performance tuning, test on a real iOS device, not on the
simulator. The simulator is a brilliant tool that speeds up the development process, but it
does not provide an accurate reflection of a real device's performance.
The simulator is running on your Mac, and the CPU in your Mac is most likely much faster
than the one in your iOS device. Conversely, the GPU in your Mac is so different from the
one in your iOS device that the simulator has to emulate the device's GPU entirely in
software (on the CPU), which means that GPU-bound operations usually run slower on the
simulator than they do on an iOS device, especially if you are writing bespoke OpenGL
code using CAEAGLLayer .
This means that testing on the simulator gives a highly distorted view of performance. If an
animation runs smoothly on the simulator, it may be terrible on a device. If it runs badly on
the simulator, it may be fine on a device. You just can't be sure.
Another important thing when performance testing is to use the Release configuration, not
Debug mode. When building for release, the compiler includes a number of optimizations
that improve performance, such as stripping debugging symbols or removing and
reorganizing code. You may also have implemented optimizations of your own, such as
disabling NSLog statements when in release mode. You only care about release
performance, so that's what you should test.
Finally, it is good practice to test on the slowest device that you support: If your base target
is iOS 6, that probably means an iPhone 3GS or iPad 2. If at all possible, test on multiple
devices and iOS versions, though, because Apple makes changes to the internals of iOS and
iOS devices in major releases and these may actually reduce performance in some cases.
For example, the iPad 3 is noticeably slower than the iPad 2 for a lot of animation and
rendering tasks because of the challenge of rendering four times as many pixels (to support
the Retina display).
Maintaining a Consistent Frame Rate
For smooth animation, you really want to be running at 60 FPS (frames per second), in sync
with the refresh rate of the screen. With NSTimer or CADisplayLink -based animations you
can get away with reducing your frame rate to 30 FPS, and you will still get a reasonable
result, but there is no way to set the frame rate for Core Animation itself. If you don't hit 60
FPS consistently, there will be randomly skipped frames, which will look and feel bad for
the user.
You can tell immediately if the frame rate is skipping badly just by using the app, but it's
difficult to see the extent of the problem just by looking at the screen, and hard to tell
whether your changes are making it slightly better or slightly worse. What you really want
is an accurate numeric display of the frame rate.
You can put a frame rate counter in your app by using CADisplayLink to measure the
frame period (as we did in Chapter 11, “Timer-Based Animation”) and then display the