Profilers Instrumenting Vs Sampling

Question

I am doing a study to between profilers mainly instrumenting and sampling. I have came up with the following info:

• sampling: stop the execution of program, take PC

Answer 1

It depends how conventional you want to be.

gprof does both those things you've mentioned. Here are some comments on that.

There is a school of thought that says profiling is about measuring. Measuring what? Well, anything - just measuring. Along with this goes the idea that what you want to get is a "big picture" of what's happening. This school looks mostly at trying to find "slow functions", without clearly defining what that even means, and telling you to look there to optimize.

Another school says that you are really debugging. You want to precisely locate bugs of a certain kind - ones that don't make the program incorrect, rather they take too long. These are not big-picture things. They are very precise points in the code where something is happening that costs a lot more time than necessary. Exactly how much more is not important. What's important is that it is located so it can be fixed. In this viewpoint, profiling overhead is irrelevant, and so is accuracy of measurement. What measuring is for is seeing how much time was saved.

One profiler that, I think, successfully spans both camps, is Zoom, because it samples the call stack, on wall-clock time, and presents, at the line/instruction level, percent of time on the stack. Some other profilers do this also, but most don't.

I'm in the second school, and here's an example of what you can accomplish with it.

Here's a more brief discussion of the issues.