Skip to content

Commit 27d9180

Browse files
Acrolinx changes.
1 parent bb9cc93 commit 27d9180

File tree

4 files changed

+287
-271
lines changed

4 files changed

+287
-271
lines changed
Lines changed: 93 additions & 86 deletions
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11
---
22
title: "Analyze Resource Consumption in XAML Apps in Visual Studio | Microsoft Docs"
33
ms.custom: "H1Hack27Feb2017"
4-
ms.date: "11/04/2016"
4+
ms.date: "11/01/2018"
55
ms.technology: "vs-ide-debug"
66
ms.topic: "conceptual"
77
ms.assetid: df7d854b-0a28-45a9-8a64-c015a4327701
@@ -12,96 +12,102 @@ ms.workload:
1212
- "uwp"
1313
---
1414
# Analyze resource consumption and UI thread activity (XAML)
15-
Use the **Application Timeline** profiler to find and fix application-interaction related performance issues in XAML applications. This tool helps improve the performance of XAML applications by providing a detailed view of the applications' resource consumption. You can analyze the time spent by your application preparing UI frames (layout and render), servicing network and disk requests, and in scenarios like Application Startup, Page Load, and Windows resize.
16-
17-
**Application Timeline** is one of the tools you can start with the **Debug** > **Performance Profiler** command.
18-
19-
This tool replaces the **XAML UI Responsiveness** tool that was part of the diagnostic toolset for Visual Studio 2013.
20-
21-
You can use this tool on the following platforms:
22-
23-
1. Universal Windows apps (on Windows 10)
24-
25-
2. Windows 8.1
26-
27-
4. Windows Presentation Foundation (.Net 4.0 and above)
28-
29-
5. Windows 7
30-
15+
16+
Use the **Application Timeline** profiler to find and fix application-interaction related performance issues in XAML applications. This tool helps improve the XAML application performance by showing a detailed view of the applications' resource consumption. You can analyze the time spent by your application preparing UI frames (layout and render), servicing network and disk requests, and in scenarios like Application Startup, Page Load, and Windows resize.
17+
18+
**Application Timeline** is one of the tools you can start with the **Debug** > **Performance Profiler** command.
19+
20+
This tool replaces the **XAML UI Responsiveness** tool that was part of the diagnostic toolset for Visual Studio 2013.
21+
22+
You can use this tool on the following platforms:
23+
24+
- Universal Windows apps (on Windows 10)
25+
- Windows 8.1
26+
- Windows Presentation Foundation (.Net 4.0 and above)
27+
- Windows 7
28+
3129
> [!NOTE]
32-
> You can collect and analyze CPU usage data and energy consumption data along with the **ApplicationTimeline** data. See [Run profiling tools with or without the debugger](../profiling/running-profiling-tools-with-or-without-the-debugger.md).
33-
34-
## Collect application timeline data
35-
You can profile the responsiveness of your app on your local machine, connected device, Visual Studio simulator or emulators, or a remote device. See [Run profiling tools with or without the debugger](../profiling/running-profiling-tools-with-or-without-the-debugger.md).
30+
> You can collect and analyze CPU usage data and energy consumption data along with the **ApplicationTimeline** data. See [Run profiling tools with or without the debugger](../profiling/running-profiling-tools-with-or-without-the-debugger.md).
3631
32+
## Collect application timeline data
33+
34+
You can profile the responsiveness of your app on your local machine, connected device, Visual Studio simulator or emulators, or a remote device. See [Run profiling tools with or without the debugger](../profiling/running-profiling-tools-with-or-without-the-debugger.md).
35+
3736
> [!TIP]
38-
> If possible, run the app directly on the device. The application performance observed on the simulator or through a remote desktop connection might not be the same as the actual performance on the device. On the other hand, collecting the data by using the Visual Studio Remote Tools does not affect the performance data.
39-
40-
Here are the basic steps:
41-
42-
1. Open your XAML app.
43-
44-
2. Click **Debug / Performance Profiler**. You should see a list of profiling tools in the .diagsession window.
45-
46-
3. Select **Application Timeline** and then click **Start** at the bottom of the window.
47-
48-
> [!NOTE]
49-
> You might see a User Account Control window requesting your permission to run *VsEtwCollector.exe*. Click **Yes**.
50-
51-
4. Run the scenario you are interested in profiling in your app to collect performance data.
52-
53-
5. To stop profiling, switch back to the .diagsession window and click **Stop** at the top of the window.
54-
55-
Visual Studio analyzes the collected data and displays the results.
56-
57-
![Timeline profiler report](../profiling/media/timeline_base.png "TIMELINE_Base")
58-
59-
## Analyze timeline profiling data
60-
After you have collected the profiling data, you can use these steps to start your analysis:
61-
62-
1. Examine the information in the **UI thread utilization** and **Visual throughput (FPS)** graphs and then use the timeline navigation bars to select a time range that you want to analyze.
63-
64-
2. Using the information in the **UI thread utilization** or **Visual throughput (FPS)** graphs, examine the details in the **Timeline details** view to discover possible causes for any apparent lack of responsiveness.
65-
66-
### <a name="BKMK_Report_scenarios_categories_and_events"></a> Report scenarios, categories, and events
67-
The **Application Timeline** tool displays timing data for scenarios, categories, and events that are related to XAML performance.
68-
69-
### <a name="BKMK_Diagnostic_session_timeline"></a> Diagnostic session timeline
70-
![Performance and Diagnostics timeline](../profiling/media/diaghub_timelinewithusermarks.png "DIAGHUB_TimelineWithUserMarks")
71-
72-
The ruler at the top of the page shows the timeline for profiled information. This timeline applies to both the **UI thread utilization** graph and the **Visual throughput** graph. You can narrow the scope of the report by dragging the navigation bars on the timeline to select a segment of the timeline.
73-
74-
The timeline also displays any user marks that you have inserted, and the app's activation lifecycle events.
75-
76-
### <a name="BKMK_UI_thread_utilization_graph"></a> UI thread utilization graph
77-
![CPU Utilization Graph](../profiling/media/timeline_cpuutilization.png "TIMELINE_CpuUtilization")
78-
79-
The **UI thread utilization (%)** graph is a bar chart that displays the relative amount of time spent in a category for during a collection span.
80-
81-
### <a name="BKMK_Visual_throughput_FPS_graph"></a> Visual throughput (FPS) graph
82-
![Visual throughput graph](../profiling/media/timeline_visualthroughput.png "TIMELINE_VisualThroughput")
83-
84-
The **Visual throughput (FPS)** line graph shows the frames per second (FPS) on the UI and composition thread for the app.
85-
86-
### <a name="BKMK_Timeline_details_"></a> Timeline details
87-
The details view is where you will be spending most of your time analyzing the report. It shows a detailed view of CPU utilization of your application categorized by the UI Framework subsystem or the system component that consumed the CPU.
88-
89-
The following events are supported:
90-
37+
> If possible, run the app directly on the device. The application performance observed on the simulator or through a remote desktop connection might not be the same as the actual performance on the device. On the other hand, collecting the data by using the Visual Studio Remote Tools doesn't affect the performance data.
38+
39+
Here are the basic steps:
40+
41+
1. Open your XAML app.
42+
43+
2. Click **Debug / Performance Profiler**. You should see a list of profiling tools in the .diagsession window.
44+
45+
3. Select **Application Timeline** and then click **Start** at the bottom of the window.
46+
47+
> [!NOTE]
48+
> You might see a User Account Control window requesting your permission to run *VsEtwCollector.exe*. Click **Yes**.
49+
50+
4. Run the scenario you are interested in profiling in your app to collect performance data.
51+
52+
5. To stop profiling, switch back to the .diagsession window and click **Stop** at the top of the window.
53+
54+
Visual Studio analyzes the collected data and displays the results.
55+
56+
![Timeline profiler report](../profiling/media/timeline_base.png "TIMELINE_Base")
57+
58+
## Analyze timeline profiling data
59+
60+
After you have collected the profiling data, you can use these steps to start your analysis:
61+
62+
1. View the information in the **UI thread utilization** and **Visual throughput (FPS)** graphs and then use the timeline navigation bars to select a time range that you want to analyze.
63+
64+
2. Using the information in the **UI thread utilization** or **Visual throughput (FPS)** graphs, examine the details in the **Timeline details** view to find possible causes for any seeming lack of responsiveness.
65+
66+
### <a name="BKMK_Report_scenarios_categories_and_events"></a> Report scenarios, categories, and events
67+
68+
The **Application Timeline** tool displays timing data for scenarios, categories, and events that are related to XAML performance.
69+
70+
### <a name="BKMK_Diagnostic_session_timeline"></a> Diagnostic session timeline
71+
72+
![Performance and Diagnostics timeline](../profiling/media/diaghub_timelinewithusermarks.png "DIAGHUB_TimelineWithUserMarks")
73+
74+
The ruler at the top of the page shows the timeline for profiled information. This timeline applies to both the **UI thread utilization** graph and the **Visual throughput** graph. You can narrow the scope of the report by dragging the navigation bars on the timeline to select a segment of the timeline.
75+
76+
The timeline also displays any user marks that you've inserted, and the app's activation lifecycle events.
77+
78+
### <a name="BKMK_UI_thread_utilization_graph"></a> UI thread utilization graph
79+
80+
![CPU Utilization Graph](../profiling/media/timeline_cpuutilization.png "TIMELINE_CpuUtilization")
81+
82+
The **UI thread utilization (%)** graph is a bar chart that displays the relative amount of time spent in a category for during a collection span.
83+
84+
### <a name="BKMK_Visual_throughput_FPS_graph"></a> Visual throughput (FPS) graph
85+
86+
![Visual throughput graph](../profiling/media/timeline_visualthroughput.png "TIMELINE_VisualThroughput")
87+
88+
The **Visual throughput (FPS)** line graph shows the frames per second (FPS) on the UI and composition thread for the app.
89+
90+
### <a name="BKMK_Timeline_details_"></a> Timeline details
91+
92+
The details view is where you spend most of your time analyzing the report. It shows the CPU use by your application categorized by the UI Framework subsystem or the system component that consumed the CPU.
93+
94+
The following events are supported:
95+
9196
|||
9297
|-|-|
93-
|**Parsing**|Time spent parsing XAML files and creating objects.<br /><br /> Expanding a **Parsing** node in **Timeline details** displays the dependency chain of all the XAML files that were parsed as a result of the root event. This will enable you to identify unnecessary file parsing and object creation in performance sensitive scenarios and optimize them out.|
94-
|**Layout**|In large applications, thousands of elements may be shown on the screen at the same time. This might result in a low UI frame rate and correspondingly poor application responsiveness. The Layout event accurately determines the cost of laying out each element (that is, the time spent in Arrange, Measure, ApplyTemplate, ArrangeOverride, and MeasureOverride) and builds the visual trees that took part in a Layout pass. You can use this visualization to determine which of your logical trees to prune, or to evaluate other deferral mechanisms to optimize your layout pass.|
98+
|**Parsing**|Time spent parsing XAML files and creating objects.<br /><br /> Expanding a **Parsing** node in **Timeline details** displays the dependency chain of all the XAML files that were parsed because of the root event. This tip lets you identify unnecessary file parsing and object creation in performance sensitive scenarios and optimize them out.|
99+
|**Layout**|In large applications, thousands of elements may be shown on the screen at the same time. This display might result in a low UI frame rate and correspondingly poor application responsiveness. The Layout event accurately determines the cost of laying out each element (that is, the time spent in Arrange, Measure, ApplyTemplate, ArrangeOverride, and MeasureOverride). It also builds the visual trees that took part in a Layout pass. You can use this visualization to determine which logical trees to prune, or to evaluate other deferral mechanisms to optimize your layout pass.|
95100
|**Render**|Time spent drawing XAML elements to the screen.|
96101
|**I/0**|Time spent retrieving data from the local disk or from network resources that are accessed through the [Microsoft Windows Internet (WinINet) API](/windows/desktop/WinInet/portal).|
97-
|**App Code**|Time spent executing application (user) code that is not related to parsing or layout.|
102+
|**App Code**|Time spent executing application (user) code that isn't related to parsing or layout.|
98103
|**Xaml Other**|Time spent executing XAML runtime code.|
99104

100105
> [!TIP]
101-
> Choose the **CPU Usage** tool along with the **Application Timeline** tool when you start profiling to view app methods that execute on the UI thread. Moving long-running app code to a background thread can improve UI responsiveness.
106+
> Choose the **CPU Usage** tool along with the **Application Timeline** tool when you start profiling to view app methods that execute on the UI thread. Moving long-running app code to a background thread can improve UI responsiveness.
102107
103-
#### <a name="BKMK_Customizing_Timeline_details_"></a> Customizing Timeline details
104-
Use the **Timeline details** toolbar to sort, filter, and specify the annotations of **Timeline details** view entries.
108+
#### <a name="BKMK_Customizing_Timeline_details_"></a> Customizing Timeline details
109+
110+
Use the **Timeline details** toolbar to sort, filter, and specify the annotations of **Timeline details** view entries.
105111

106112
|||
107113
|-|-|
@@ -110,9 +116,10 @@ Use the **Application Timeline** profiler to find and fix application-interactio
110116
|![Filter timeline details list](../profiling/media/timeline_filter.png "TIMELINE_Filter")|Filters the list by selected categories and the length of events.|
111117
|![Customize timeline details information](../profiling/media/timeline_viewsettings.png "TIMELINE_ViewSettings")|Lets you specify the annotations to events.|
112118

113-
## See also
114-
[WPF team blog: New UI performance analysis tool for WPF applications](https://blogs.msdn.microsoft.com/wpf/2015/01/16/new-ui-performance-analysis-tool-for-wpf-applications/)
115-
[Performance best practices for UWP apps using C++, C#, and Visual Basic](/previous-versions/windows/apps/hh750313\(v\=win.10\))
116-
[Optimize WPF application performance](/dotnet/framework/wpf/advanced/optimizing-wpf-application-performance)
117-
[Profiling in Visual Studio](../profiling/index.md)
118-
[First look at profiling tools](../profiling/profiling-feature-tour.md)
119+
## See also
120+
121+
- [WPF team blog: New UI performance analysis tool for WPF applications](https://blogs.msdn.microsoft.com/wpf/2015/01/16/new-ui-performance-analysis-tool-for-wpf-applications/)
122+
- [Performance best practices for UWP apps using C++, C#, and Visual Basic](/previous-versions/windows/apps/hh750313\(v\=win.10\))
123+
- [Optimize WPF application performance](/dotnet/framework/wpf/advanced/optimizing-wpf-application-performance)
124+
- [Profiling in Visual Studio](../profiling/index.md)
125+
- [First look at profiling tools](../profiling/profiling-feature-tour.md)

0 commit comments

Comments
 (0)