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 and thus deduce were the program is
• instrumenting: add some overhead code to the program so it would increment some pointers to know the program

If the above info is wrong correct me.

After this I was looking at the time of execution and some said that instrumenting takes more time than sampling! is this correct?

if yes why is that? in sampling you have to pay the price of context switching between processes while in the latter your in the same program no cost

Am i missing something?

cheers! =)

Answer 1

The interrupts generated by a sampling profiler generally add an insignficant amount of time to the total execution time, unless you have a very short sampling interval (e.g. < 1 ms).

With instrumented profiling there can be a large overhead, e.g. on small leaf functions that get called many times, as the calls to the instrumentation library can be significant compared to the execution time of the function.

Answer 2

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.