Merge pull request #7366 from Mikejo5000/mikejo-br18

Memory usage updates for profiling - links and clarifications

Author: v-shmck

docs/profiling/analyze-memory-usage.md

@@ -15,9 +15,15 @@ To find memory leaks and inefficient memory usage, you can use tools such as the
 
 The Memory Usage tool lets you take one or more *snapshots* of the managed and native memory heap. You can collect snapshots of .NET, ASP.NET, C++, or mixed mode (.NET and native) apps. The **Memory 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 **Memory 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). In the debugger, you can turn memory profiling on and off, and see a per-object breakdown of memory usage. You can view memory usage results when execution is paused, for example at a breakpoint.
 
-.NET developers may choose between either the [Memory usage](../profiling/memory-usage.md) tool and the [.NET Object Allocation tool](../profiling/dotnet-alloc-tool.md).
-- The **.NET Object Allocation** tool helps you identify allocation patterns and anomalies in your .NET code, and helps identify common issues with garbage collection. This tool runs only as a post-mortem tool. You can run this tool on local or remote machines.
-- The **Memory usage** tool is helpful in identifying memory leaks, which are not typically common in .NET apps. If you need to use debugger features while checking memory, such as stepping through code, the [debugger-integrated Memory usage](../profiling/beginners-guide-to-performance-profiling.md) tool is recommended.
+.NET developers may choose between either the .NET Object Allocation tool or the [Memory usage](../profiling/memory-usage.md) tool.
+
+- The [.NET Object Allocation tool](../profiling/dotnet-alloc-tool.md) helps you identify allocation patterns and anomalies in your .NET code, and helps identify common issues with garbage collection. This tool runs only as a post-mortem tool. You can run this tool on local or remote machines.
+- The [Memory Usage tool](../profiling/memory-usage-without-debugging2.md) is helpful in identifying memory leaks, which are not typically common in .NET apps. If you need to use debugger features while checking memory, such as stepping through code, the [debugger-integrated Memory usage](../profiling/memory-usage.md) tool is recommended.
+
+C++ developers can use either the debugger-integrated or non-debugger Memory Usage tool.
+
+- [Analyze memory usage with the debugger](../profiling/memory-usage.md)
+- [Analyze memory usage without the debugger](../profiling/memory-usage-without-debugging2.md)
 
 You can use the profiling tools without the debugger with Windows 7 and later. Windows 8 and later is required to run profiling tools with the debugger (**Diagnostic Tools** window).
 
@@ -29,6 +35,5 @@ You can use the profiling tools without the debugger with Windows 7 and later. W
 
 ## See also
 
-- [Analyze memory usage without the debugger](../profiling/memory-usage-without-debugging2.md)
 - [Profiling in Visual Studio](../profiling/index.yml)
 - [First look at profiling tools](../profiling/profiling-feature-tour.md)

docs/profiling/memory-usage-without-debugging2.md

@@ -18,7 +18,7 @@ ms.workload:
 
 The **Memory Usage** tool monitors your app's memory use. You can use the tool to study the real-time memory effects of scenarios you're actively developing in Visual Studio. You can take detailed snapshots of the app's memory states, and compare snapshots to find the root causes of memory issues. The Memory Usage tool is supported on .NET, ASP.NET, C++, or mixed mode (.NET and native) apps.
 
-The Memory Usage tool can run [with or without the debugger](../profiling/running-profiling-tools-with-or-without-the-debugger.md). In this article, we show how to use the Memory Usage tool without the debugger in the Visual Studio **Performance Profiler**.
+The Memory Usage tool can run [with or without the debugger](../profiling/running-profiling-tools-with-or-without-the-debugger.md). In this article, we show how to use the Memory Usage tool without the debugger in the Visual Studio **Performance Profiler**, which is recommended for release builds.
 
 ## Memory Usage diagnostic sessions
 

docs/profiling/profiling-feature-tour.md

@@ -56,8 +56,8 @@ For more information on using the CPU Usage or Memory usage tool in the Performa
 Tools available in the Performance Profiler include:
 
 - [CPU usage](../profiling/cpu-usage.md)
-- [Memory usage for .NET code](../profiling/dotnet-alloc-tool.md)
-- [Memory usage](#analyze-memory-usage)
+- [.NET object allocation](../profiling/dotnet-alloc-tool.md)
+- [Memory usage](../profiling/memory-usage-without-debugging2.md)
 - [.NET async tool](../profiling/analyze-async.md)
 - [Database tool](../profiling/analyze-database.md)
 - [GPU usage](../profiling/gpu-usage.md)
@@ -101,7 +101,12 @@ Double-click on a function that you are interested in, and you will see a more d
 
 ## Analyze memory usage
 
-The **Diagnostic Tools** window also allows you to evaluate memory usage in your app using the **Memory Usage** tool. For example, you can look at the number and size of objects on the heap. You can use the [debugger-integrated Memory Usage tool](../profiling/memory-usage.md) or the [post-mortem Memory Usage tool](../profiling/memory-usage-without-debugging2.md) in the Performance Profiler. Another memory analysis tool, the [.NET Object Allocation tool](../profiling/dotnet-alloc-tool.md), helps you identify allocation patterns and anomalies in your .NET code.
+The **Diagnostic Tools** window also allows you to evaluate memory usage in your app using the **Memory Usage** tool. For example, you can look at the number and size of objects on the heap. You can use the [debugger-integrated Memory Usage tool](../profiling/memory-usage.md) or the [post-mortem Memory Usage tool](../profiling/memory-usage-without-debugging2.md) in the Performance Profiler.
+
+.NET developers may choose between either the [.NET Object Allocation tool](../profiling/dotnet-alloc-tool.md) or the [Memory usage](../profiling/memory-usage.md) tool.
+
+- The **.NET Object Allocation** tool helps you identify allocation patterns and anomalies in your .NET code, and helps identify common issues with garbage collection. This tool runs only as a post-mortem tool. You can run this tool on local or remote machines.
+- The **Memory usage** tool is helpful in identifying memory leaks, which are not typically common in .NET apps. If you need to use debugger features while checking memory, such as stepping through code, the [debugger-integrated Memory usage](../profiling/beginners-guide-to-performance-profiling.md) tool is recommended.
 
 To analyze memory usage with the **Memory Usage** tool, you need to take at least one memory snapshot. Often, the best way to analyze memory is to take two snapshots; the first right before a suspected memory issue, and the second snapshot right after a suspected memory issue occurs. Then you can view a diff of the two snapshots and see exactly what changed. The following illustration shows taking a snapshot with the debugger-integrated tool.
 
@@ -163,7 +168,7 @@ In your UWP apps, you can enable **UI Analysis** in the **Diagnostic Tools** win
 
 In Direct3D apps (Direct3D components must be in C++), you can examine activity on the GPU and analyze performance issues. For more information, see [GPU Usage](./gpu-usage.md). To use the tool, choose **GPU Usage** in the Performance Profiler, and then choose **Start**. In your app, go through the scenario that you're interested in profiling, and then choose **Stop collection** to generate a report.
 
-When you select a time period in the graphs and choose **view details**, a detailed view appears in the lower pane. In the detailed view, you can examine how much activity is happening on each CPU and GPU. Select events in the lowest pane to get popups in the timeline. For example, select the **Present** event to view **Present** call popups. (The light gray vertical Vsync lines can be used as a reference to understand whether certain **Present** calls missed Vsync. There must be one **Present** call between every two Vsyncs in order for the app to steadily hit 60 FPS.)
+When you select a time period in the graphs and choose **view details**, a detailed view appears in the lower pane. In the detailed view, you can examine how much activity is happening on each CPU and GPU. Select events in the lowest pane to get popups in the timeline. For example, select the **Present** event to view **Present** call popups. (The light gray vertical VSync lines can be used as a reference to understand whether certain **Present** calls missed VSync. There must be one **Present** call between every two VSyncs in order for the app to steadily hit 60 FPS.)
 
 ![GPU Usage profiling tool](../profiling/media/prof-tour-gpu-usage.png "Diag GPU Usage")
 

docs/profiling/running-profiling-tools-with-or-without-the-debugger.md

@@ -25,6 +25,7 @@ To help decide which tools and results to use, consider the following:
   - External performance problems, like file I/O or network responsiveness issues, won't look much different in the debugger or non-debugger tools.
   - The debugger itself changes performance times, as it does necessary debugger operations like intercepting exception and module load events.
   - Release build performance numbers in the Performance Profiler are the most precise and accurate. Debugger-integrated tool results are most useful to compare with other debugging-related measurements, or to use debugger features.
+  - Some tools, such as the .NET Object Allocation tool, are only available for non-debugger scenarios.
 - Debug vs. release build
   - For problems caused by CPU-intensive calls, there might be considerable performance differences between release and debug builds. Check to see whether the issue exists in release builds.
   - If the problem occurs only during debug builds, you probably don't need to run the non-debugger tools. For release build problems, decide whether features provided by the debugger-integrated tools will help to pinpoint the problem.