How to show the number of times functions are called in Instruments Time Profiler

Question

I've tried every possible fields but can not find the number of times functions are called.

Besides, I don't get Self and # Self. What do these two numbers mean?

Answer 1

There are several other ways to accomplish this. One is obviously to create a static hit counter and an NSLog that emits and increments a counter. This is intrusive though and I found a way to do this with lldb.

1. Set a breakpoint
2. Execute the program until you hit the breakpoint the first time and note the breakpoint number on the right hand side of the line you hit (e.g. "Thread 1: breakpoint 7.1", note the 7.1)
3. Context click on the breakpoint and choose "Edit Breakpoint"
4. Leave condition blank and choose "Add Action"
5. Choose "Debugger Command"
6. In the command box, enter "breakpoint list 7.1" (using the breakpoint number for your breakpoint from step 2). I believe you can use "info break " if you are using gdb.
7. Check Options "Automatically Continue after evaluating"
8. Continue

Now, instead of stopping, llvm will emit info about the breakpoint including the number of times it has been passed.

As for the discussion between Glenn and Mike on the previous answer, I'll describe a performance problem where function execution count was useful: I had a particular action in my app where performance degraded considerably with each execution of the action. The Instruments time profiler showed that each time the action was executed, a particular function was taking twice as long as the time before until quickly the app would hang if the action was performed repeatedly. With the count, I was able to determine that with each execution, the function was called twice as many times as it was during the previous execution. It was then pretty easy to look for the reason, which turned out to be that someone was re-registering for a notification in NotificationCenter on each event execution. This had the effect of doubling the number of response handler calls on each execution and thus doubling the "cost" of the function each time. Knowing that it was doubling because it was called twice as many times and not because the performance was just getting worse caused me to look at the calling sequence rather than for reasons the function itself could be degrading over time.