How do code profilers work?

Question

While I was working on an University project, I used a project-internal profiler made by an elder student, it was very basic but good enough since its task was to subtract times between two points of the code and to give statistics.

Now, how does a professional profiler work? Does it preprocess the code to insert checkpoints or stuff like that? Does it read the binary code with debug data to catch where a function is called?

Thanks.

Answer 1

There are lots of different profilers which work in different ways.

Commonly used profilers simply examine the running program regularly to see what assembly instruction is currently being executed (the program counter) and which routines called the current function (the call stack). This kind of sampling profiler can work with standard binaries, but are more useful if you have debugging symbols to work out lines of code given addresses in the program.

As well as sampling regularly, you can also use processor performance counters to sample after a certain number of events such as cache misses, which will help you see which parts of your program are slowing down due to memory accesses.

Other profilers involve recompiling the program to insert instructions (known as instrumentation) to count how often each continuous set of instructions (basic blocks) are executed, or maybe even record the sequence in which basic blocks are executed, or record the content of variables at certain places.

The instrumentation approach can give you all the precision and data you might want, but will slow down the program and that will change its performance characteristics. By contrast, with sampling based approaches you can tune the performance impact against the length of time you need to run the program against the accuracy of the profile data you obtain.

Answer 2

There are two common profiling strategies (for VM-based languages anyway): instrumentation and sampling.

Instrumentation inserts checkpoints and informs the profiler every time a method starts and finished. This can be done by the JIT/interpreter or by a post-normal-compile but pre-execution phase which just changes the executable. This can have a very significant effect on the performance (thus skewing any timing results). It's good for getting accurate counts though.

Sampling asks the VM periodically what the stack trace looks like for all threads, and updates its statistics that way. This typically affects performance less, but produces less accurate call counts.