You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/profiling/dotnet-alloc-tool.md
+87-44Lines changed: 87 additions & 44 deletions
Original file line number
Diff line number
Diff line change
@@ -12,86 +12,129 @@ ms.workload:
12
12
---
13
13
14
14
15
-
# Analyze memory usage using the .NET Object Allocation tool
15
+
# Analyze memory usage by using the .NET Object Allocation tool
16
16
17
-
You can see how much memory your app is using and what code paths allocate the most memory using the .NET Object Allocation tool.
17
+
You can see how much memory your app uses and what code paths allocate the most memory by using the .NET Object Allocation tool.
18
18
19
-
After running the tool, you can see the function execution paths where objects are being allocated so that you can trace back to the root of the call tree that is taking up the most amount of memory.
19
+
After running the tool, you can see the function execution paths where objects are being allocated. You can then trace back to the root of the call tree that is taking up the most memory.
20
20
21
21
## Setup
22
22
23
-
1. Open the Performance Profiler (**Alt + F2)** in Visual Studio.
24
-
2. Select the **.NET Object Allocation Tracking** checkbox.
23
+
1. Select **Alt+F2** to open the performance profiler in Visual Studio.
1. Select the **.NET Object Allocation Tracking** check box.
27
26
28
-
> [!NOTE]
29
-
> The startup project is selected as the **Analysis Target** by default, but this can be changed to the running process, executables, running apps, and installed apps by opening the **Change Target** dropdown menu and then selecting from the available options.
The .NET Object Allocation tool does not currently support executables via the dropdown menu. You will have to go through the exe project system to use the tool. To do this close your current solution (**File**-> **Close Solution**) and then hit **File** -> **Open a project or solution** -> select your .exe file.
1. After the tool starts running, go through the scenario you want to profile in your app. Then select **Stop collection** or close your app to see your data.
You can now analyze the memory allocation of the objects.
43
40
44
-
Congrats! You can now analyze the memory allocation of the objects.
41
+
During collection, the tracking tool can slow down the profiled app. If performance of the tracking tool or the app is slow, and if you don't need to track every object, you can adjust the sampling rate. To do so, select the gear symbol next to the tracking tool in the profiler summary page.
45
42
46
-
## Understand Your Data
43
+

47
44
48
-
### Collection
45
+
Adjust the sampling rate to the rate you want. This change helps speed up performance of your app during collection and analysis.
The collection view allows you to see how many objects were collected during garbage collection and how many were retained. This view also provides a few pie charts to visualize collected and survived objects by type.
49
+
For more information on how to make the tool more efficient, see [Optimizing Profiler settings](../profiling/optimize-profiler-settings.md).
53
50
54
-
- The **Collected** column shows the number of objects that the garbage collector collected.
55
-
- The **Survived** column shows the number of objects that survived after the garbage collector was run.
51
+
## Understand your data
52
+
53
+

54
+
55
+
In the preceding graphical view, the top graph shows the number of live objects in your app. The bottom **Object delta** graph shows the percentage change of app objects. Red bars denote when garbage collection took place.
56
+
57
+

58
+
59
+
You can filter the tabular data to display activity for only a specified time range. You can also zoom into or out of the graph.
The **Allocation** view shows the location of objects that are allocating memory and how much memory those objects are allocating.
66
+
67
+
- The **Type** column is a list of classes and structures that take up memory. Double-click a type to view its backtrace as an inverted call tree. In the **Allocation** view only, you can see items within the selected category that take up memory.
68
+
69
+
- The **Allocations** column shows the number of objects that take up memory within a particular allocation type or function. This column appears only in the **Allocation**, **Call Tree**, and **Functions** views.
70
+
71
+
- The **Bytes** and **Average Size (Bytes)** columns don't appear by default. To show them, right-click the **Type** or **Allocations** column, and then select the **Bytes** and **Average Size (Bytes)** options to add them to the chart.
72
+
73
+
The two columns are similar to **Total (Allocations)** and **Self (Allocations)**, except they show the amount of memory taken up instead of the number of objects taking up memory. These columns appear only in the **Allocation** view.
74
+
75
+
- The **Module name** column shows the module that contains the function or process that is calling.
76
+
77
+
All of these columns are sortable. For the **Type** and **Module Name** columns, you can sort items alphabetically in either ascending or descending order. For **Allocations**, **Bytes** and **Average Size (Bytes)**, you can sort items by increasing or decreasing numeric value.
60
78
61
-
The allocation view allows you to see the location of objects that are allocating memory and how much memory those objects are allocating.
79
+
#### Symbols
62
80
63
-
- The **Name** column is a list of various classes and structures that are taking up memory. Each item within the column is a node that can be expanded if there are items within that category taking up memory. (**Allocation** view only)
64
-
- The **Total (Allocations)** column shows the number of objects within a particular allocation type that are taking up memory. (**Allocation**, **Call Tree**, and **Functions** View)
65
-
- The **Self (Allocations)** column shows the number of objects within an individual item that is taking up memory. (**Allocation**, **Call Tree**, and **Functions** View)
66
-
- All three of these columns are sortable. In the case of the **Name** column, the items are sorted alphabetically (either forward or backwards). For **Total** and **Self (Allocations)**, you can sort numerically (either increasingly or decreasingly).
67
-
- The **Total Size (Bytes)** and **Self Size (Bytes)** columns are not on by default. To enable them, right click on the **Name**, **Total** or **Self (Allocations)** columns and then click **Total Size** and **Self Size** options to add them to the chart. The two columns are similar to **Total (Allocations)** and **Self (Allocations)** except that instead of showing the number of objects taking up memory, they show the total amount of memory in bytes that those objects are taking up. [Allocation view only]
81
+
The following symbols appear in the **Allocation**, **Call Tree**, and **Functions** tabs:
82
+
83
+
- - A value type like integer
84
+
85
+
- - A value-type collection like array of integers
86
+
87
+
- - A reference type like string
88
+
89
+
- - A reference-type collection like array of strings

72
94
73
-
The**Call Tree**view allows you to see the function execution paths that contain objects allocating a lot of memory.
95
+
The**Call Tree**view shows the function execution paths that contain objects allocating much memory.
74
96
75
-
- The **Function name** column shows the process or name of the function containing objects allocating memory based on the level of the node you are inspecting.
76
-
- The **Total** and **Self (Allocations)** columns show the same information as the **Allocation** view.
77
-
- The **Module name** column shows the module that contains the function or process that is calling.
97
+
- The **Function Name** column shows the process or name of the function containing objects that allocate memory. The display is based on the level of the node you're inspecting.
98
+
- The **Total (Allocations)** and **Total Size (Bytes)** columns show the number of allocated objects and the amount of memory that is used by a function and all other functions it calls.
99
+
- The **Self (Allocations)** and **Self-Size (Bytes)** columns show the number of allocated objects and the amount of memory that is used by a single selected function or allocation type.
100
+
- The **Average Size (Bytes)** column shows the same information as it does in the **Allocations** view.
101
+
- The **Module name** column shows the module that contains the function or process that is calling.

80
104
81
-
- The **Expand Hot Path** button highlights a function execution pathway that contains a lot of objects that are allocating memory. The algorithm starts at a user-selected node of interest and highlights the path of most allocations, guiding a user in their investigation.
82
-
- The **Show Hot Path** button toggles on or off the flame icons that indicate which node are a part of the **Hot Path**.
105
+
- The **Expand Hot Path** button highlights a function execution pathway that contains many objects that are allocating memory. The algorithm starts at a node you select and highlights the path of the most allocations, guiding you in your investigation.
106
+
- The **Show Hot Path** button shows or hides the flame symbols that indicate which nodes are part of the hot path.
The **Collection** view shows how many objects were collected or retained during garbage collection. This view also shows pie charts to visualize collected and survived objects by type.
128
+
129
+
- The **Collected** column shows the number of objects that the garbage collector collected.
130
+
- The **Survived** column shows the number of objects that survived after the garbage collector was run.
131
+
132
+
### Filtering tools
133
+
134
+
The **Allocations**, **Call Tree**, and **Functions** views all contain the **Show Just My Code** and **Show Native Code** options and a filter box.
92
135
93
-
The **Allocations**, **Call Tree**, and **Functions** views all contain the **Show Just My Code**, **Show Native Code**, and **Search** options:
-**Show Just My Code** collapses systems, frameworks, and other non-user code and into **[External Code]** frames so that user-code can be focused on. For more information, see [Debug user code with Just My Code](../debugger/just-my-code.md).
96
-
-**Show Native Code** shows native code within the analysis target including non-user code if selected.
97
-
-The **Filter box** allows you to filter down the **Name** or **Function name** column based on the parameter you provide. Simply type in the field and the table should filter down to show only types that contain the string provided.
138
+
-**Show Just My Code** collapses systems, frameworks, and other nonuser code into **[External Code]** frames so that you can focus on just your code. For more information, see [Debug user code with Just My Code](../debugger/just-my-code.md).
139
+
-**Show Native Code** shows native code within the analysis target and can include nonuser code.
140
+
-With the filter box, you can filter down the **Name** or **Function name** column based on the value you provide. Enter a string value in the box. The table then shows only types that contain that string.
0 commit comments