How Does The RedGate Profiler Actually Work

It seems that the Ants profiler does instrumentation and sampling of code at exactly the same time which I find very interesting

I have used the VS profiler and you hav开发者_如何转开发e to run two different profile sessions to identify bottlenecks - How does ANTS capture IO bound function calls without modifying and injecting code into the compiled functions?

EDIT: Does ants use instrumentation or sampling?

The Ants profiler offers several different profiling modes, some of which use sampling and some of which use instrumentation (the instrumentation modes are only available in the professional edition, and the sampling mode was introduced fairly recently). A brief description of the modes that are available is here, as well as a comparison between the different modes.

RedGate doesn't publish technical details about how their profiler works, but from experimentation I haven't found any significant differences from how other profilers work (just a different user interface, and I'm sure there are optimizations in some areas or fringe features that aren't available in other profilers). Based on your question I'm guessing you're somewhat familiar with other profilers, but if you're interested in how it works on a lower level, here's a brief overview:

In sampling mode, the profiler will periodically run OS interrupts to pause program execution, and checks what method the program is currently in. Every method in a binary or intermediate-language assembly consists of an instruction set. When a program is executed, every thread will progress along that instruction set, jumping to a different instruction set location when a method is invoked. The current location for the threads execution can be though of as a pointer to a location in this instruction set, and you can find out the address is for the instruction set for a given method. So a profiler builds a map of instruction set locations to method names, and when it pauses the program it checks where the current execution is. By mapping it to the method name, it can count the number of times that method has been invoked and how long it is taking to run. But since this is only a sample, there may be other methods that were called that we didn't notice because they returned before we paused the program in the next interval.

In instrumentation mode, the profiler will inject additional instructions into the program's instruction sets. Lets say you have an instruction set A->B->C that is invoked when the doSomething() method is called. A very crude profiler could inject additional instructions to do something like

long starttime = currentTime()
A
B
C
long endtime = currentTime() - starttime

this will tell you how much time it took to run the method. Of course, modern profilers do much more elaborate instructions than this to optimize performance, get performance on a per-line basis, get memory and IO information as well as timing information, etc, but the principle is the same.

Modern OSes also have a decent capability to get hardware-level diagnostics as well, so that profilers can get more detailed information about most of the systems, including memory, disk IO, CPU utilization, etc. How these different systems work are very device and driver specific.

Note that this injection can be done at various stages - on the source level, on the binary level before execution, at runtime, etc. Especially with languages like C#, where there is an intermediate stage between compilation and assembly execution (the CLR), it's easier to inject these additional instructions at runtime. It also allows you to surround methods within the internal .NET framework (such as the IO operations that I think you are asking about) with custom instructions at runtime, so that you can get performance information even if you don't have the original source code. This again relies on its ability to build a mapping from instruction sets to method names, but the difference is that you can still inject the additional instructions without having to resort to sampling. I think there are special precautions you can take to make this more difficult, but there's no real incentive for Microsoft to do this to the internals of the .NET framework.

If the Ants Profiler you are referring to is the one from RedGate then this is for .NET runtimes. I suspect that they are using the very extensive API for profiling applications, provided by Microsoft; I suggest you look for ICorProfilerCallback/2/3 and ICorProfilerInfo/2/3 for starters. The API allows for instrumentation and filtered callbacks for method entry/exit calls and other features.

Some open source (or code available) profilers of interest I suspect for you based on your query are CLRProfiler4 (Microsoft) and SlimTune.