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/beginners-guide-to-performance-profiling.md
+17-3Lines changed: 17 additions & 3 deletions
Original file line number
Diff line number
Diff line change
@@ -20,7 +20,7 @@ ms.workload:
20
20
---
21
21
# Measure application performance by analyzing CPU usage
22
22
23
-
You can use Visual Studio profiling tools to analyze performance issues in your application. This procedure shows how to use **CPU Usage** tab of the Diagnostics Tools to obtain performance data for your app.
23
+
You can use Visual Studio profiling tools to analyze performance issues in your application. This article shows how to use **CPU Usage** tab of the Diagnostics Tools to obtain performance data for your app, and also provides information on using PerfTips.
24
24
25
25
When the debugger pauses, the **CPU Usage** tool collects information about the functions that are executing in your application. The tool lists the functions that were performing work, and provides a timeline graph you can use to focus on specific segments of the sampling session.
26
26
@@ -45,8 +45,7 @@ In this tutorial, you will:
45
45
46
46
2. Set a second breakpoint at the end of the function or region of code that you want to analyze.
47
47
48
-
> [!TIP]
49
-
> By setting two breakpoints, you can limit data collection to the parts of code that you want to analyze.
48
+
By setting two breakpoints, you can limit data collection to the parts of code that you want to analyze.
50
49
51
50
3. The **Diagnostic Tools** window appears automatically unless you have turned it off. To bring up the window again, click **Debug** > **Windows** > **Show Diagnostic Tools**.
52
51
@@ -72,10 +71,16 @@ In this tutorial, you will:
72
71
73
72
When you choose **Record CPU Profile**, Visual Studio will begin recording your functions and how much time they take to execute. You can only view this collected data when your application is halted at a breakpoint.
74
73
74
+
> [!TIP]
75
+
> To help analyze performance, you can also use [PerfTips](../profiling/perftips.md) to step through code and identify how long it takes particular functions or code blocks to complete.
76
+
75
77
8. Hit F5 to run the app to your second breakpoint.
76
78
77
79
Now, you now have performance data for your application specifically for the region of code that runs between the two breakpoints.
78
80
81
+
>[!TIP]
82
+
> When paused at a breakpoint or a code-stepping operation, you can also analyze performance using [PerfTips](#analyze-performance-using-perftips).
83
+
79
84
The profiler begins preparing thread data. Wait for it to finish.
> When trying to identify performance issues, take multiple measurements. Performance naturally varies from run-to-run, and code paths typically execute slower the first time they run due to one-time initialization work such as loading DLLs, JIT compiling methods, and initializing caches. By taking multiple measurements, you get a better idea of the range and median of the metric being shown, whichs allow you to compare the first time versus the steady state performance of an area of code.
100
+
93
101
## Step 2: Analyze CPU usage data
94
102
95
103
We recommend that you begin analyzing your data by examining the list of functions under CPU Usage, identifying the functions that are doing the most work, and then taking a closer look at each one.
@@ -150,6 +158,12 @@ We recommend that you begin analyzing your data by examining the list of functio
150
158
> [!NOTE]
151
159
> If you see code in the call tree marked as "broken" code or "unwalkable stack", this indicates that Event Tracing for Windows (ETW) events were likely dropped. Try collecting the same trace a second time to resolve the issue.
152
160
161
+
## Analyze performance using PerfTips
162
+
163
+
While running code in the debugger, you can also use [PerfTips](../profiling/perftips.md) for in-depth performance analysis. Using PerfTips, you can view performance information while interacting with your code. You can check information such as the duration of the event (measured from when the debugger was last paused, or when the app started). For example, if you step through code (F10, F11), PerfTips show you the app runtime duration from the previous step operation to the current step.
164
+
165
+
![Analyze with PerfTips](../profiling/media/diag-tools-perftips.png"AnalyzeWithPerfTips")
166
+
153
167
## View external code
154
168
155
169
External code are functions in system and framework components that are executed by the code you write. External code include functions that start and stop the app, draw the UI, control threading, and provide other low-level services to the app. In most cases, you won't be interested in external code, and so the CPU Usage tool gathers the external functions of a user method into one **[External Code]** node.
> To help analyze performance, you can also use [PerfTips](#examine-performance-events-using-perftips) to step through code and identify how long it takes particular functions or code blocks to complete.
53
+
54
+
## Examine performance events using PerfTips
55
+
56
+
Often, the easiest way to view performance information is to use [PerfTips](../profiling/perftips.md). Using PerfTips, you can view performance information while interacting with your code. You can check information such as the duration of the event (measured from when the debugger was last paused, or when the app started). For example, if you step through code (F10, F11), PerfTips show you the app runtime duration from the previous step operation to the current step.
57
+
58
+
![Profiling Tour PerfTips](../profiling/media/prof-tour-perf-tips.png"Profiling Tour PerfTips")
59
+
60
+
You can use PerfTips to examine how long it takes for a code block to execute, or how long it takes for a single function to complete.
61
+
62
+
PerfTips show the same events that also show up in the **Events** view of the Diagnostic Tools. In the **Events** view, you can view different events that occur while you are debugging, such as the setting of a breakpoint or a code stepping operation.
> If you have Visual Studio Enterprise, you can also see [IntelliTrace events](../debugger/intellitrace.md) in this tab.
68
+
51
69
## Analyze memory usage
52
70
53
71
The **Diagnostic Tools** window also allows you to evaluate memory usage in your app. For example, you can look at the number and size of objects on the heap. For more detailed instructions to analyze memory, see [Analyze memory usage](../profiling/memory-usage.md).
@@ -62,19 +80,6 @@ When you select one of the arrow links, you are given a differential view of the
62
80
63
81
If you click the link on the left instead in the **Memory Usage** view, the heap view is organized by object count; the objects of a particular type that increased the most in number are shown at the top (sorted by **Count Diff** column).
64
82
65
-
## Examine performance events
66
-
67
-
The **Events** view in the Diagnostic Tools shows you different events that occur while you are debugging, such as the setting of a breakpoint or a code stepping operation. You can check information such as the duration of the event (measured from when the debugger was last paused, or when the app started). For example, if you step through code (F10, F11), the **Events** view shows you the app runtime duration from the previous step operation to the current step.
> If you have Visual Studio Enterprise, you can also see [IntelliTrace events](../debugger/intellitrace.md) in this tab.
73
-
74
-
The same events also show up in the code editor, which you can view as PerfTips.
75
-
76
-
![Profiling Tour PerfTips](../profiling/media/prof-tour-perf-tips.png"Profiling Tour PerfTips")
77
-
78
83
## <aname="post_mortem"></a> Profile release builds without the debugger
79
84
80
85
Profiling tools like CPU Usage and Memory Usage can be used with the debugger (see earlier sections), or you can run profiling tools post-mortem using the Performance Profiler, which is intended to provide analysis for **Release** builds. In the Performance Profiler, you can collect diagnostic info while the app is running, and then examine the collected information after the app is stopped. For more information on these different approaches, see [Run profiling tools with or without the debugger](../profiling/running-profiling-tools-with-or-without-the-debugger.md). Additional tools such as the [.NET Object Allocation tool](../profiling/dotnet-alloc-tool.md) are also available in the Performance Profiler.
Copy file name to clipboardExpand all lines: docs/profiling/quickstart-cpu-usage-native.md
+4-2Lines changed: 4 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -136,8 +136,10 @@ Windows 8 and later is required to run profiling tools with the debugger (**Diag
136
136
137
137
![Set breakpoints for profiling](../profiling/media/quickstart-cpu-usage-breakpoints-cplusplus.png"Set breakpoints for profiling")
138
138
139
-
> [!TIP]
140
-
> By setting two breakpoints, you can limit data collection to the parts of code that you want to analyze.
139
+
By setting two breakpoints, you can limit data collection to the parts of code that you want to analyze.
140
+
141
+
>[!TIP]
142
+
> When paused at a breakpoint or a code-stepping operation, you can also analyze performance using [PerfTips](../profiling/perftips.md).
141
143
142
144
3. The **Diagnostic Tools** window is already visible unless you have turned it off. To bring up the window again, click **Debug** > **Windows** > **Show Diagnostic Tools**.
0 commit comments