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

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.

While it's interesting, knowing the number of times called doesn't have anything to do with how much time is spent in them. Which is what Time Profiler is all about. In fact, since it does sampling, it cannot answer how many times.

It seems you cannot use Time Profiler for counting function calls. This question seems to address potential methods for counting.

W/ respect to self and #self:

Self is "The number of times the symbol calls itself." according to the Apple Docs on the Time Profiler.

From the way the numbers look though, it seems self is the summed duration of samples that had this symbol at the bottom of its stack trace. That would make:

• # self: the number of samples where this symbol was at the bottom of the stack trace
• % self: the percent of self samples relative to total samples of currently displayed call tree
  • (eg - #self / total samples).

So this wouldn't tell you how many times a method was called. But it would give you an idea how much time is spent in a method or lower in the call tree.

NOTE: I too am unsure about the various 'self' meanings though. Would love to see someone answer this authoritatively. Arrived here searching for that...