Sampling profilers

In the case of sampling profilers, the profiler will periodically examine the state of the program by taking a snapshot of its current stack and looking at the function where the program is currently at. The idea is that the most sampled functions will also be the functions that take most of the program's execution time. In the long run, these two values will converge and we will obtain an image of the most-used functions.

The first disadvantage is obvious—due to its statistical nature, sampling results for less-used functions can be imprecise; a function might be missed, but could also be sampled disproportionately, often if the profiling run is too short. The second disadvantage is more subtle—sampling records data in a non-discriminatory way providing information on every function in the system, resulting in a data deluge, when, as we already know, only a small part of the code is interesting performance-wise.

 The clear advantage of such profilers, however, is their non-invasive nature. As they are independent of build tool chains, such profilers are very easy to use and are the most commonly employed in software development today. Some examples of such profilers are the Visual Studio profiler, Very Sleepy, and Luke Stackwalker, among many others. Even the venerable gprof is a mixed-type instrumenting and sampling profiler.

In reality, you might like to use both types of profiling: manual instrumentation for your profile builds and general overview, and sampling profilers for more detailed data when investigating a specific problem.