how does a c# profiler work?

Question

I'm curious how does a typical C# profiler work?

Are there special hooks in the virtual machine?

Is it easy to scan the byte code for function calls and inject calls to start/stop timer?

Or is it really hard and that's why people pay for tools to do this?

(as a side note i find a bit interesting bec it's so rare - google misses the boat completely on the search "how does a c# profiler work?" doesn't work at all - the results are about air conditioners...)

Answer 1

There is a free CLR Profiler by Microsoft, version 4.0.

https://www.microsoft.com/downloads/en/details.aspx?FamilyID=be2d842b-fdce-4600-8d32-a3cf74fda5e1

BTW, there's a nice section in the CLR Profiler doc that describes how it works, in detail, page 103. There's source as part of distro.

Answer 2

Is it easy to scan the byte code for function calls and inject calls to start/stop timer?

Or is it really hard and that's why people pay for tools to do this?

Injecting calls is hard enough that tools are needed to do it.

Not only is it hard, it's a very indirect way to find bottlenecks. The reason is what a bottleneck is is one or a small number of statements in your code that are responsible for a good percentage of time being spent, time that could be reduced significantly - i.e. it's not truly necessary, i.e. it's wasteful. IF you can tell the average inclusive time of one of your routines (including IO time), and IF you can multiply it by how many times it has been called, and divide by the total time, you can tell what percent of time the routine takes. If the percent is small (like 10%) you probably have bigger problems elsewhere. If the percent is larger (like 20% to 99%) you could have a bottleneck inside the routine. So now you have to hunt inside the routine for it, looking at things it calls and how much time they take. Also you want to avoid being confused by recursion (the bugaboo of call graphs).

There are profilers (such as Zoom for Linux, Shark, & others) that work on a different principle. The principle is that there is a function call stack, and during all the time a routine is responsible for (either doing work or waiting for other routines to do work that it requested) it is on the stack. So if it is responsible for 50% of the time (say), then that's the amount of time it is on the stack, regardless of how many times it was called, or how much time it took per call. Not only is the routine on the stack, but the specific lines of code costing the time are also on the stack. You don't need to hunt for them. Another thing you don't need is precision of measurement. If you took 10,000 stack samples, the guilty lines would be measured at 50 +/- 0.5 percent. If you took 100 samples, they would be measured as 50 +/- 5 percent. If you took 10 samples, they would be measured as 50 +/- 16 percent. In every case you find them, and that is your goal. (And recursion doesn't matter. All it means is that a given line can appear more than once in a given stack sample.)

On this subject, there is lots of confusion. At any rate, the profilers that are most effective for finding bottlenecks are the ones that sample the stack, on wall-clock time, and report percent by line. (This is easy to see if certain myths about profiling are put in perspective.)