Instruments tutorial Part 3 - Profile Performance - Time Profiler - CPU Usage

After 2. Part of this series, you can now, what is Instruments, how it works, how can you launch it and what type of analysis can you make with that, how can you use the Navigate Timeline Pane and Detail Pane, how can you hide system libraries, add flags to your Timeline at serious points, or add new Instrument to it, or check the source code in Xcode, which causes problems. 

Now I'll show you, how can use these things with Time Profiler, to find problems in your Project, and solve these high CPU/low-overhead problem. These are usually code bugs, not allocations but it can be several type of mistakes, and you have to find a better code or solution, or sometimes you use unnecessary code. It can help you check your project, and not just find problems, because you can test it with your updated code again, and see if the problem is still exist. 


  1. Record a Trace & Simulate user actions
  2. Hide System Library and Check the problems in your code blocks
  3. Detect the exact row of the problem
  4. Update the code and test it again
  5. Cores & Threads
  6. Other ways

Part of the series

  1. Instruments tutorial Part 1 - Profiling templates, deferred mode, launch instruments
  2. Instruments tutorial Part 2 - Navigate Timeline Pane, Detail Pane, Hide System Library
  3. Instruments tutorial Part 4 - Profile Performance - Graphics Performance - Core Animation, OpenGl Activity
  4. Instruments tutorial Part 5 - Profile Performance - Monitor NetWork - Network
  5. Instruments tutorial Part 6 - Profile Memory - Activity Monitor
  6. Instruments tutorial Part 7 - Profile Memory - Allocations
  7. Instruments tutorial Part 8 - Profile Memory - Leaks
  8. Instruments tutorial Part 9 - Profile Memory - Zombies
  9. Instruments tutorial Part 10 - Profile Energy - Energy Impact
  10. Instruments tutorial Part 11 - Create Custom Instrument
  11. Instruments tutorial Part 12 - Automate UI Testing


Time Profiler, why you need to use this Profiler?

"The Time Profiler profiling template uses the Time Profiler instrument to perform low-overhead, time-based sampling of processes running on the system’s CPUs. The more effectively multiple cores and threads are used over time, the better an app’s performance. The CPU and thread strategies in the Time Profiler instrument show how well an app utilizes cores and threads.
Use the CPU strategy usage view to compare core usage over given time periods. Effective core concurrency improves an app’s performance. Look for unbalanced core usage. If a single core has areas of heavy usage while other cores remain quiet, that can indicate areas that need greater optimization. When zoomed out, activity may appear to be occurring on multiple threads, but a closer inspection may reveal otherwise. Therefore, be sure to zoom in on the track pane when examining core usage.
Use the threads strategy view to examine your app’s use of threads when performing work. Large amounts of work on the main thread can make your app’s user interface unresponsive or slow. Whenever possible, work should be moved off the main thread."

Intruments UserGuide

1. Record a Trace

Please see the Video, it's better to see the process and not just screenshots.

At first step you need to recording what you are actually doing with your application in your Simulator or on your Device. For the best results, it's better to use on your device that will be real data. 

In Xcode long press the play button and select Profile instead of Running (or check the first tutorials for more option to launch Instruments).

Click on the Red button, do your staff in your app. Try to check at first just one action, and repeat it 2-3 times. After that, you can stop the recording, and see the results. If there are some problems with your code, you will see at your trace some significant high results. And if you've repeated the same action, you can see the same high values at every time, when you are doing the same action.

I use for this tutorial my earlier Core Data iCloud Sync tutorial Xcode Project.

2. Hide System Library and Check the problems in your code blocks

You can Hide System Libraries, and with that you can reach your code in the list. If you select a period of your Trace, you will see just that part of codes in the list. Click one of your code in the list - I'm click on textFieldDidBeginEditing.. and at right side select the "Extended Detail" view. Here you can see the same code with black. This is your code, you can click on it. And You can find which row or rows of your code needs more time, and cause high signs at the trace.

3. Detect the exact row of the problem

Sometimes Instruments shows you the problem some rows under the exact problematic code. You should figure it out, for example in my video, I'm sure, that the 100% result doesn't depend on UITextField Placeholder, rather than reloudInputView, or AppDelegate. So I check them in Xcode (Clicking on Xcode icon in Instruments), and I'm trying to use another code, or just delete it, if it mustn't have. 

At Toolbar, you can reach the 3 Strategy buttons, the "CPU", the "Instruments", and the "Threads". These are very useful. With "CPU" you can see the Cores, with "Threads" you can see all threads which were used during the time of recording. At "Instruments" you can see the data at the timeline pane.  

Instruments 2 Inspector Pane Details

At "Extended Detail", you can see which part of your code detected. You can click on it to see your source code details. However, better first select a Range. 

4. Update the code and test it again

I'm deleting the reloudInputView code in the video, and I'm running again the Time Profiler. After repeating the user actions again, I'm searching for the same block of code in the list. But I can't find it. That means, that was the problem. Sometimes you need to delete that part of code, sometimes you can detect the problem with this way, and you need to find another better way to write that code. I'm doing something like that with the next block, the ViewDidLoad method. Here the problem appears at placeholder again, but I'm sure, that the Appdelegate cause the problem. And yes, if I open the project in Xcode, there is a warning there. So I try another method (not the final solution, just I did something for the video tutorial). After that I test it again, and there isn't more problem with ViewDidLoad block in Instruments. So with that steps, you can check your whole project. This is the fastest and easiest way to find, if something isn't the best in your Xcode project. But if you want to check a specific type of bug (allocation, or high energy or core graphics..) you need to use a specific profiler. I'll show them in this tutorial series. 

5. Cores & Threads

If you are using more threads in your App, you can check them separately with Time Profiler. Just click on Threads icon in the right corner, or CPU icon, so you can check the threads or Cores separately. It could be very useful. 

6. Other ways

I suggest to test CPU always on real device not just in Simulator. You can also test with Activity Monitor, or System Trace profiler. If you test with these in Simulator, you will find in your Instruments your other system process too, for example Skype, or Postgres processes too. So just with real Device! 


 The next part of the series: Blender Test + UITableView Scroll Performance - Instruments tutorial Part 4 - Profile Performance - Graphics Performance, Core Animation

Share & Follow

If you would like to be notified of my new solutions, please subscribe to my Newsletter or my youtube channel and/ or follow me on Facebook or Twitter! Check Footer section for these opportunities!