Skip to content

Commit 30f58aa

Browse files
authored
Merge pull request #7927 from MicrosoftDocs/main637860710948398931
For protected CLA branch, push strategy should use PR and merge to target branch method to work around git push error
2 parents 5e7d18b + ad068f8 commit 30f58aa

11 files changed

+23
-20
lines changed

docs/debugger/using-breakpoints.md

Lines changed: 5 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -60,12 +60,15 @@ For most languages including C#, breakpoint and current execution lines are auto
6060

6161
When you debug, execution pauses at the breakpoint, before the code on that line is executed. The breakpoint symbol shows a yellow arrow.
6262

63-
At the breakpoint in the following example, the value of `testInt` is still 1. So, the value hasn't changed since the variable was initialized (set to a value of 1) because the statement in yellow hasn't yet executed.
64-
6563
::: moniker range=">= vs-2022"
64+
At the breakpoint in the following example, the value of `testInt` is still 3. So, the value hasn't changed since the variable was initialized (set to a value of 3) because the statement in yellow hasn't yet executed.
65+
6666
![Breakpoint execution stopped](../debugger/media/vs-2022/breakpoint-execution.png "Breakpoint execution")
6767
::: moniker-end
68+
6869
::: moniker range="<= vs-2019"
70+
At the breakpoint in the following example, the value of `testInt` is still 1. So, the value hasn't changed since the variable was initialized (set to a value of 1) because the statement in yellow hasn't yet executed.
71+
6972
![Breakpoint execution stopped](../debugger/media/breakpointexecution.png "Breakpoint execution")
7073
::: moniker-end
7174

docs/profiling/cpu-usage.md

Lines changed: 18 additions & 18 deletions
Original file line numberDiff line numberDiff line change
@@ -14,7 +14,11 @@ ms.workload:
1414
---
1515
# Analyze CPU usage without debugging in the Performance Profiler (C#, Visual Basic, C++, F#)
1616

17-
A good way to start investigating performance issues in your app is to understand its CPU usage. The **CPU Usage** performance tool shows the CPU time and percentage spent executing code in C++, C#/Visual Basic, and JavaScript apps.
17+
A good way to start investigating performance issues in your app is to understand its CPU usage. The **CPU Usage** performance tool shows the CPU time and percentage spent executing code in C++, C#/Visual Basic, and JavaScript apps. If you need to diagnose a slow-down or a process hang in your team’s codebase, the CPU Usage tool can help you diagnose the issue with your team’s production code. The tool provides automatic insights and various views of your data so that you can analyze and diagnose performance issues.
18+
19+
The tool is also helpful for DevOps scenarios, such as when a customer reports that some requests or orders are not getting through to the retail website during peak season. Often, the issues are in production, and it is challenging to debug at that moment, but this tool can help you capture enough information and evidence of the issue. After collecting a trace file, the analysis can quickly help you understand potential causes and give suggestions within the context of your code so that you can take the next steps to fix the issue.
20+
21+
The **CPU Usage** tool is helpful for both local trace sessions and production. It can also be initiated by using the keyboard shortcut, **Alt+F2**, and then **CPU Usage** or by opening an already collected trace using a tool like dotnet-trace or dotnet-monitor.
1822

1923
The CPU Usage tool can run on an open Visual Studio project, on an installed Microsoft Store app, or attached to a running app or process. You can run the CPU Usage tool with or without debugging. For more information, see [Run profiling tools with or without the debugger](../profiling/running-profiling-tools-with-or-without-the-debugger.md).
2024

@@ -29,21 +33,21 @@ Usually, the local machine best replicates installed app execution. To collect d
2933

3034
1. In the Visual Studio project, set the solution configuration to **Release** and select **Local Windows Debugger** (or **Local Machine**) as the deployment target.
3135

32-
![Select Release and Local Machine](../profiling/media/cpuuse_selectreleaselocalmachine.png "Select Release and Local Machine")
36+
![Select Release and Local Machine](../profiling/media/vs-2022/cpu-use-select-release.png "Select Release")
3337

3438
1. Select **Debug** > **Performance Profiler**.
3539

3640
1. Under **Available tools**, select **CPU Usage**, and then select **Start**.
3741

38-
![Select CPU Usage](../profiling/media/cpuuse_lib_choosecpuusage.png "Select CPU Usage")
42+
![Select CPU Usage](../profiling/media/vs-2022/cpu-use-lib-choose-cpu-usage.png "Select CPU Usage")
3943

4044
4. After the app starts, the diagnostic session begins and displays CPU usage data. When you're finished collecting data, select **Stop Collection**.
4145

42-
![Stop CPU Usage data collection](../profiling/media/cpu_use_wt_stopcollection.png "Stop CPU Usage data collection")
46+
![Stop CPU Usage data collection](../profiling/media/vs-2022/cpu-use-wt-stop-collection.png "Stop CPU Usage data collection")
4347

4448
The CPU Usage tool analyzes the data and displays the report.
4549

46-
![CPU Usage report](../profiling/media/cpu_use_wt_report.png "CPU Usage report")
50+
![CPU Usage report](../profiling/media/vs-2022/cpu-use-wt-report.png "CPU Usage report")
4751

4852
## Analyze the CPU Usage report
4953

@@ -68,10 +72,10 @@ To view the call tree, select the parent node in the report. The **CPU Usage** p
6872
#### <a name="BKMK_Call_tree_structure"></a> Call tree structure
6973

7074
::: moniker range=">=vs-2019"
71-
![Call tree structure](../profiling/media/vs-2019/cpu-use-wt-getmaxnumbercalltree-annotated.png "Call tree structure")
75+
![Call tree structure](../profiling/media/vs-2022/cpu-use-wt-call-tree-annotated.png "Call tree structure")
7276
::: moniker-end
7377
::: moniker range="vs-2017"
74-
![Call tree structure](../profiling/media/cpu_use_wt_getmaxnumbercalltree_annotated.png "Call tree structure")
78+
![Call tree structure](../profiling/media/vs-2022/cpu-use-wt-call-tree-annotated.png "Call tree structure")
7579
::: moniker-end
7680

7781
|Image|Description|
@@ -85,34 +89,30 @@ To view the call tree, select the parent node in the report. The **CPU Usage** p
8589

8690
System and framework functions that are executed by your code are called *external code*. External code functions start and stop the app, draw the UI, control threading, and provide other low-level services to the app. In most cases, you aren't interested in external code, so the CPU Usage call tree gathers the external functions of a user method into one **[External Code]** node.
8791

88-
To view the call paths of external code, on the main diagnostic report page (right pane), select **Show External Code** from the **Filter** dropdown, and then select **Apply**. The **Call Tree** view of the **CPU Usage** page then expands the external code calls. (The **Filter** dropdown is available on the main diagnostic page, not the detailed views.)
92+
To view the call paths of external code, switch the current view to the **Call Tree** view or right-click and select **View in Call Tree**.
8993

90-
![Show External Code](../profiling/media/cpu_use_wt_filterview.png "Show External Code")
94+
![Show Call Tree](../profiling/media/vs-2022/cpu-use-wt-call-tree-view.png "Show Call Tree")
9195

92-
Many external code call chains are deeply nested, so the width of the chain can exceed the display width of the **Function Name** column. The function names then appear as **...**.
96+
Many external code call chains are deeply nested, so the width of the chain can exceed the display width of the **Function Name** column. The function names then appear as shown in the following image.
9397

94-
![Nested external code in the call tree](../profiling/media/cpu_use_wt_showexternalcodetoowide.png "Nested external code in the call tree")
98+
![Nested external code in the call tree](../profiling/media/vs-2022/cpu-use-wt-show-external-code.png "Nested external code in the call tree")
9599

96100
To find a function name you're looking for, use the search box. Hover over the selected line or use the horizontal scroll bar to view the data.
97101

98102
::: moniker range=">=vs-2019"
99-
![Search for nested external code](../profiling/media/vs-2019/cpu-use-wt-showexternalcodetoowide-found.png "Search for nested external code")
103+
![Search for nested external code](../profiling/media/vs-2022/cpu-use-wt-search.png "Search for nested external code")
100104
::: moniker-end
101105
::: moniker range="vs-2017"
102-
![Search for nested external code](../profiling/media/cpu_use_wt_showexternalcodetoowide_found.png "Search for nested external code")
106+
![Search for nested external code](../profiling/media/vs-2022/cpu-use-wt-search.png "Search for nested external code")
103107
::: moniker-end
104108

105109
### <a name="BKMK_Asynchronous_functions_in_the_CPU_Usage_call_tree"></a> Asynchronous functions in the CPU usage call tree
106110

107111
When the compiler encounters an asynchronous method, it creates a hidden class to control the method's execution. Conceptually, the class is a state machine. The class has compiler-generated functions that asynchronously call the original methods, and the callbacks, scheduler, and iterators needed to run them. When a parent method calls the original method, the compiler removes the method from the execution context of the parent, and runs the hidden class methods in the context of the system and framework code that controls app execution. The asynchronous methods are often, but not always, executed on one or more different threads. This code appears in the **CPU Usage** call tree as children of the **[External Code]** node immediately below the top node of the tree.
108112

109-
In the following example, the first two nodes under **[External Code]** are the compiler-generated methods of the state machine class. The third node is the call to the original method.
110-
111-
![Asynchronous node](media/cpu_use_wt_getmaxnumberasync_selected.png "Asynchronous node")
112-
113113
Expand the generated methods to show what's going on:
114114

115-
![Expanded asynchronous node](media/cpu_use_wt_getmaxnumberasync_expandedcalltree.png "Expanded asynchronous node")
115+
![Expanded asynchronous node](media/vs-2022/cpu-use-wt-expanded-call-tree.png "Expanded asynchronous node")
116116

117117
- `MainPage::GetMaxNumberAsyncButton_Click` just manages a list of the task values, computes the maximum of the results, and displays the output.
118118

Loading
Loading
Loading
Loading
Loading
Loading
Loading
Loading
Loading

0 commit comments

Comments
 (0)