This document summarizes Greg Heo's presentation on profiling and performance for iOS apps. It begins with a survey showing most developers use Instruments' Leaks tool but few use its time profiling. It then discusses reasons to and not to profile an app, emphasizing the need to measure and optimize bottlenecks. The document outlines tips for using Instruments like hiding system libraries and reviews its useful call tree and annotated code views. It concludes by stressing the importance of profiling before and after changes to verify performance improvements and then shipping the updated app.
1. Profiling & Performance
for fun and profit
Greg Heo (@gregheo)
11 January 2012
Hi there! @gregheo at the keys. These are the slides and presentation notes from my #iOSTO talk.
Please feel free to get in touch if you have any questions or comments.
2. Survey
• Developers?
• Instruments users?
• Profiling enthusiasts?
Survey shows: lots of developers; some instruments users (mostly using the “Leaks” tool); and only
a handful of time profiling users.
3. Why to not Profile?
• You might not need to!
iOS users demand excellent performance. Credit goes to Apple for a well-performing API too. We
developers have very few excuses for poor performance.
5. Why Profile?
• The app is slow!
Refactoring code (especially other people’s code) is what programmers love doing. Resist! Think
bug/feature regression and possible delays.
7. “Measure twice, cut once”
– carpenters?
You must have an objective measure. Re-factor and optimize the bottlenecks and hotspots to get
the most value in terms of programmer time invested vs. outcome.
8.
9.
10. Items to note: the playback/recording metaphor; the purple chart shows CPU usage.
14. Summary
• Profile, fix, profile again.
• Ship the app already!
Profile before and after to verify performance has indeed improved. Use the tools; they’re there to
help!
