[. Net Program Performance Analysis-Part 2] Use CLR profiler to analyze. net programs

It's like stripping. net syntax sugar tool (reflector and so on) a lot of the same, we can be used for analysis. there are many tools for net program performance, such as the performance analysis tool provided by vs introduced in the previous blog debuglzq. In addition, common tools include CLR profiler and windbg.

　　Vs built-in Performance AnalysisYou can quickly find the bottleneck code and support multithreading.

　　WindbgI will not talk about it more. Windows platform provides powerful user-mode and kernel-mode debugging tools! Windbg also provides graphic interface operations, but it has powerful Debugging commands in the most powerful part and is difficult to use.

Here we mainly want to talk aboutCLR ProfileThe detection results are the most detailed. However, because the detection of managed heap allocation and garbage collection will affect the running speed of the application, it is impossible to get a performance test in time.

Introduction to CLR profiler

CLR profiler is a tool used to observe managed heap memory allocation and study garbage collection behavior. Using different views in this tool, you can obtain useful information about your application execution, memory allocation and consumption. CLR profiler analysis results are stored in log files. Common views are as follows:

View	Description
Histogram allocated types	Gives you a high-level view of what object types are allocated (by allocation size) during the lifetime of your application. this view also shows those objects that are allocated in the large object heap (objects larger than 85 KB ). This view allows you to click parts of the graph so that you can see which methods allocated which objects.
Histogram relocated types	Displays the objects that the garbage collector has moved because they have specified ved a garbage collection.
Objects by address	Provides a picture of what is on the managed heap at a given time.
Histogram by age	Allows you to see the life time of the objects on the managed heap.
Allocation Graph	Graphically displays the call stack for how objects were allocated. You can use this view: -See the cost of each allocation by method. -Isolate allocations that you were not expecting. -View possible excessive allocations by a method.
Assembly, module, function, and class graph	These four views are very similar. They allow you to see which methods pulled in which assemblies, functions, modules, or classes.
Heap Graph	Shows you all of the objects in the managed heap, along with their connections.
Call Graph	Lets you see which methods call which other methods and how frequently. You can use this graph to get a feel for the cost of library calland to determine how many callare made to methods and which methods are called.
Time line	Displays what the garbage collector does over the lifetime of the application. Use this view: -Investigate the behavior of the garbage collector. -Determine how collect garbage collections occur at the three generations (generation 0, 1, and 2) and how frequently they occur. -Determine which objects keep ve garbage collection and are promoted to the next generation. You can select time points or intervals and right-click to show who allocated memory in the interval.
Call Tree View	Provides a text-based, chronological, hierarchical view of your application's execution. Use this view: -See what types are allocated and their size. -See which assemblies are loaded as result of method CILS. -Analyze the use of finalizers, including the number of finalizers executed. -Identify methods whereCloseOrDisposeHas not been implemented or called, thereby causing a bottleneck. -Analyze allocations that you were not expecting.

The following is an example of the previous Code to introduce various functions. The Code is as follows:

Using system; using system. collections. generic; using system. LINQ; using system. text; namespace vs2010 performance test {class program {static void main (string [] ARGs) {int start = environment. tickcount; For (INT I = 0; I <1000; I ++) {string S = ""; for (Int J = 0; j <200; j ++) {S + = "outer Index ="; S + = I; S + = "inner Index ="; S + = J; S + = "";}} int middle = environment. tickcount; console. writeline ("program Part1 run for {0} seconds", 0.001 * (middle-Start); // For (INT I = 0; I <1000; I ++) {stringbuilder S = new stringbuilder (); For (Int J = 0; j <200; j ++) {S. append ("outer Index ="); S. append (I); S. append ("inner Index ="); S. append (j); S. append ("") ;}} int end = environment. tickcount; console. writeline ("program Part2 run for {0} seconds", 0.001 * (end-middle); // console. readkey ();}}}

 

The running interface of the CLR profiler program is as follows:

Use start application to select the program to be run, and you can choose whether to track memory allocation and method calls. When the application is closed (automatically or manually), profiler automatically starts to sort the results. The analysis result is stored in the log file and displayed as follows:

The report statistics page is as follows:

 Heap statistics stack statistics: This test program of debuglzq needs to allocate 6 GB of memory! Have you ever thought of it?

Allocation graph: displays the distribution of stacks in charts.

Allocated Bytes: the object allocated by the application throughout the startup cycle. Sort by object size. Objects of different color codes are listed on the right. For example, the red is a string object.

Relocated Bytes: it is moved by the object in the managed heap during GC. Different colors represent different objects.

(This section briefly introduces the GC process. There are two steps: there are specific algorithms to determine which objects are spam (that is, traverse the objects referenced in the list based on the Root reference list, objects that cannot be traversed); moving objects that are not spam in the heap)

Final heap Bytes: it is still in the heap. Color indicates the type.

 Garbage collection statistics: GC statistics.A total of 4501 times of 0-generation garbage collection were performed!

The Time View is as follows. The recovery time and memory usage (4501 times in total) are clearly displayed ).

 GC handle: count the number of GC handles

The details are as follows:

Let's introduce it here.

For more details, please refer to the detailed description on the CLR profiler documentation page. This document is in the root directory of the file you have released, and is named clrprofiler.doc.

 

[Hope to help you ~ Click "Green Channel" --- "follow debuglzq" below to share progress ~]