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

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?

---

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...

---

IF your objective is to find out what you need to fix to make the program as fast as possible,

Number of calls and self time may be interesting but are irrelevant.

Look at my answer to this question, in particular points 6 and 8.

EDIT: To clarify the point further, suppose the following is the timeline of execution of the program. Some of that time (in this case about 50%) is spent in an activity that can be removed, if you know what it is, such as needless buried I/O, excessive calls to new, runaway notifications, or "insignificant" data validation. If a random-time sample is taken, it has a 50% chance of occurring in that activity, and an examination of the call stack and/or program variables shows that it is doing something that can be removed. Then, if 10 such samples are taken, the activity will be seen on roughly 5 of them, regardless of whether the activity occurs in a few large chunks of time, or many small ones. The activity may be a few lines of code in a function doing something unnecessary, or it may be something much more generalized. Regardless, you recognize it, fix it, and get roughly a factor of 2 speedup. Call counts and self time contribute nothing to this process.