Introduction

What is a sampling profiler?

There are basically two kinds of profiling tools: instrumenting profilers (source or binary) and sampling profilers. Instrumenting profilers work by altering an application code or binary, and adding calls to functions that will count how many time each procedure was called and how many time was spent inside. This approach allows an exhaustive analysis of which code called which code, and how many times was spent in each procedures. However, it will typically incur a significant execution speed and memory penalty that can only be avoided by spending time and insight and limiting instrumentation to a subset of an application's functions, making them more suitable when you know where the issue is (see GpProfile for a free instrumenting Delphi profiler).

Sampling profilers on the other hand do not require instrumentation and proceed by a statistical analysis by periodically looking at which code is currently being executed by the profiled application. The statistical nature means that not all code may be seen by the profiler (only code that takes time to execute), profiling information may vary randomly between executions and context information for bottlenecks is typically limited.

Why should I use a sampling profiler?

Using a sampling profilers has benefits:

• it will not affect the execution speed measurably, neither because of its own execution times, nor because it affects the CPU instruction or data cache by its instrumenting code (ie. you get a measure of actual performance like if there was no profiler running)
• it is able to measure the time spent in other OS components or DLLs (like the video driver, OpenGL, etc.), not just the time spent in your application
• profiling latencies won't hide your application's latencies (hard disk accesses, network accesses, video driver waits...), which can be particularly significant if your application makes asynchronous accesses.
• it can pinpoint bottlenecks at the code-line level (not just procedure level), for the entire application.
• it can be used to profile over long periods of time, like a full batch run of computations or a complete game level, you can literally have an application being profiled for days
• being lightweight, you can profile multiple applications simultaneously (like a client and a server running on the same development machine)

Note that unlike SamplingProfiler also offers callers information and statistics, thus providing information typically found only in instrumenting profilers. It will even go a little step further than some instrumenting profiler by being able to identify the caller at the line level (if procedure A calls procedure B on three different lines, it will be able to pinpoint which of those three call points is critical, and not just that A called B, or that one of the call points called B more times than the other).

Created with the Personal Edition of HelpNDoc: Easy EBook and documentation generator