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 have 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.
Related
I read that
One way to understand how the processor used its time is to look at
the hardware counters. To help with performance tuning, modern
processors track various counters as they execute code: the number of
instructions executed, the number of various types of memory accesses,
the number of branches encountered, and so forth. To read the
counters, you’ll need a tool such as the profiler in Visual Studio
2010 Premium or Ultimate, AMD Code Analyst or Intel VTune.
So what is the way to do it by coding like using PerformanceCounter And get this number of instructions executed ?
And is there any way to count the hit of instructions like DotTrace,Ants, VS profiler do it ?
For the VS Profiler:
To view a list of a list of all CPU counters that are supported on the current platform
In Performance Explorer, right-click the performance session and then click Properties.
Do one of the following:
Click Sampling, and then select Performance counter from the Sample event list. The CPU counters are listed in Available performance counters.
Note Click Cancel to return to the previous sampling configuration.
-or-
Select CPU Counters, and then select Collect CPU Counters. The CPU counters are listed in Available counters.
Note Click Cancel to return to the previous counter collection configuration.
You can't access the full CPU counters from your program, because: https://stackoverflow.com/a/8800266/613130
You can use RDPMC instruction or __readpmc MSVC compiler intrinsic, which is the same thing.
However, Windows prohibits user-mode applications to execute this instruction by setting CR4.PCE to 0. Presumably, this is done because the meaning of each counter is determined by MSR registers, which are only accessible in kernel mode. In other words, unless you're a kernel-mode module (e.g. a device driver), you are going to get "privileged instruction" trap if you attempt to execute this instruction.
(RDPMC is the instruction that returns the CPU counters)
I'll add that normally the number of instructions executed is quite useless. What is important is the CPU time that was used to execute some code. Each instruction has a different CPU time, so even knowing the number of them, you wouldn't know the number of CPU cycles/time used.
If you want to know the CPU cycles used for some instructions, then you can use the ASM instruction RDTSC/RDTSCP. Using it in C# is complex and quite time-consuming (so using it is slow enough that it often compromises the measuring you are trying to do). If you are interested, I wrote a response about it some days ago: https://stackoverflow.com/a/29646856/613130
Already answered to your question, so i think this is duplicating question.
It's native methods in WinAPI most likely, you can invoke them from C# via DLLImport. But for simplicity you could try use third party wrapper from here.
But you should clearly understand what you are doing. Between first call of your function and the second one will be difference because of JITting time. And if your method allocates memory - GC might occur any time while calling your method and it will be reflected in measurement.
I am thinking about adding a diagnostics mode build into an app I am writing to count method usage and execution time, similar to what many code profilers like dotTrace do.
I'm having some trouble finding resources through google on how to accomplish this though; obviously it is possible, but can anyone point me to some resources on how I can implement something like method call counts in .NET?
The Code Project article Creating a Custom .NET Profiler describes the process of creating a profiler using the CLR profiler hooks.
This involves creating a COM object that implements the ICorProfilerCallback2 interface and then using environment variables to indicate to the CLR that we wish to profile by using this class:
When the CLR begins a process, it looks for two environment variables:
COR_ENABLE_PROFILING: This environment variable is set to either 1 or 0. 1 indicates that the CLR should use a profiler. 0 (or the non-existence of this environment variable) indicates that it should not use a profiler.
COR_PROFILER: Now that we've told the CLR that we want to profile, we have to tell it which profiler to use. Because profilers are implemented as COM objects, this environment variable will be set to the GUID of the coclass that implements the ICorProfilerCallback2 interface.
Perhaps I am being too simple here, but my solution to this would be logging. Using entlib or log4net and log debug level messages. Then you can just write a little script/program to analyse the log file and give you the method count. There might even be other log diagnostic tools.
Unless you need rich visualization or real time complex relationship mapping etc. Would you need a profiler? For method count and execution time, wouldn't a log file suffice? Once you are in production or don't care about instrumentation you turn your logging level up and forget about those debug messages.
I have written various C# console based applications, some of them long running some not, which can over time have a large memory foot print. When looking at the windows perofrmance monitor via the task manager, the same question keeps cropping up in my mind; how do I get a break down of the number objects by type that are contributing to this footprint; and which of those are f-reachable and those which aren't and hence can be collected. On numerous occasions I've performed a code inspection to ensure that I am not unnecessarily holding on objects longer than required and disposing of objects with the using construct. I have also recently looked at employing the CG.Collect method when I have released a large number of objects (for example held in a collection which has just been cleared). However, I am not so sure that this made that much difference, so I threw that code away.
I am guessing that there are tools in sysinternals suite than can help to resolve these memory type quiestions but I am not sure which and how to use them. The alternative would be to pay for a third party profiling tool such as JetBrains dotTrace; but I need to make sure that I've explored the free options first before going cap in hand to my manager.
There is the CLR Profiler that lets you review various object graphs (I've never used it):
http://www.microsoft.com/downloads/details.aspx?FamilyID=86ce6052-d7f4-4aeb-9b7a-94635beebdda&displaylang=en
Of course, ANTS Profiler (free trial) is an often recommended profiler. You shouldn't need to manually garbage collect, the GC is a very intelligently built solution that will likely be more optimal than any manual calls you do. A better approach is to be minimalist with the number of objects you keep in memory - and be rid of memory-heavy objects as soon as possible if memory is priority.
I am trying to get some detailed performance information from an application my company is developing. Examples of information I am trying to get would be how long a network transaction takes, how much CPU/memory the application is using, how long it takes for a given method to complete, etc.
I have had some failed attempts at this in the past (like trying to measure small time periods by using DateTime.Now). On top of that I don't know much of anything about getting CPU and memory statistics. Are there any good .Net classes, libraries, or frameworks out there that would help me collect this sort of information and/or log it to a text file?
What you are looking for is Performance Counters. For .net you need this Performance Counter.
Performance counters are one way to go, and the System.Diagnostics.Stopwatch class are good foundational places to look for doing this.
With performance counters (beyond those provided) you will need to manage both the infrastructure of tracking the events, as well as reporting the data. The performance counter base classes supply the connection details for hooking up to the event log, but you will need to provide other reporting infrastructure if you need to report the data in another way (such as to a log file, or database).
The stopwatch class is a wrapper around the high performance timer, giving you microsecond or nanosecond resolution depending on the processor or the platform. If you do not need that high of resolution you can use System.DateTime..Now.Ticks to get the current tick count for the processor clock and do differential math with that, giving you millisecond or bettter precision for most operations.
When tracking CPU statistics be aware that multiple processors and multiple cores will complicate any accurate statistics in some cases.
One last caution with performance counters, be aware that not all performance counters are on all machines. For instance ASP.NET counters are not present on a machine which does not have IIS installed, etc.
for a modern opensource library to do performance metrics and monitoring consider using app-metrics.
github: https://github.com/AppMetrics/AppMetrics
website https://www.app-metrics.io
A platform independent open source performance recorder build on top of aspect injector can be found here: https://gitlab.com/hectorjsmith/csharp-performance-recorder. It can be added to any C# project. Instructions on how to use can be found in the README in Gitlab.
Benefits
It's aspect oriented, meaning you don't have to litter your code with DateTime.Now - you just annotate the appropriate methods
It takes care of pretty printing the results - you can do with the what you like e.g. printing them to a file
Notes
This performance recorder is focused on the timing of methods only. It doesn't cover CPU or memory usage.
For cpu/memory use performance counters. For more specific information about specific methods (or lines of code) and specific objects, use a profiler. red-gate makes a great profiler.
http://www.red-gate.com/products/ants_performance_profiler
I've been researching a bit about .NET Performance counters, but couldn't find anything detailed (unlike the rest of the framework).
My question is: Which are the most relevant performance counters to get the maximum computing power of the machine? Well, the .NET virtual machine, that is..
Thank you,
Chuck Mysak
You haven't described what you mean by "computing power". Here are some of the things you can get through performance counters that might be relevant:
Number of SQL queries executed.
Number of IIS requests completed.
Number of distributed transactions committed.
Bytes of I/O performed (disk, network, etc.).
There are also relative numbers, such as percentages of processor and memory in use which can give an indication of how much of the "power" of your system is actually being used.
However, you will not find anything that correlates cleanly with raw computing "power". In fact, who is to say that the machine's full "power" is being taken advantage of at the time you look at the counters? It sounds like what you really want to do is run a benchmark, which includes the exact work to be performed and the collection of measurements to be taken. You can search the Internet for various benchmark applications. Some of these run directly in .NET while the most popular are native applications which you could shell out to execute.