Clarify scenarios for running profiling tools in debug or release builds

Author: Mikejo5000

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

@@ -1,38 +1,33 @@
 ---
-title: "Run profiling tools with or without the debugger"
-description: Explore the differences between running profiling tools for your applications in Visual Studio with or without the debugger.
-ms.date: "11/09/2023"
+title: "Run profiling tools on release or debug builds"
+description: Explore the differences between running profiling tools for your applications in Visual Studio on release or debug builds.
+ms.date: "01/06/2024"
 ms.topic: "conceptual"
 author: "mikejo5000"
 ms.author: "mikejo"
 manager: mijacobs
 ms.subservice: debug-diagnostics
 ---
-# Run profiling tools with or without the debugger (C#, Visual Basic, C++, F#)
+# Run profiling tools on release or debug builds (C#, Visual Basic, C++, F#)
 
-Visual Studio offers a choice of performance measurement and profiling tools. Some tools, like CPU Usage and Memory Usage, can run with or without the debugger, and on release or debug build configurations. Tools that appear in the [Diagnostics Tools window](../profiling/profiling-feature-tour.md#measure-performance-while-debugging) run only during a debugging session. Tools that appear in the [Performance Profiler](../profiling/profiling-feature-tour.md#post_mortem) run without the debugger and you analyze the results after you choose to stop and collect data (for post-mortem analysis).
+Visual Studio offers a choice of performance measurement and profiling tools. Some tools, like CPU Usage and Memory Usage, can run either on release builds or while debugging your app. Tools that appear in the [Diagnostics Tools window](../profiling/profiling-feature-tour.md#measure-performance-while-debugging) run only during a debugging session using a debug build. Tools that appear in the [Performance Profiler](../profiling/profiling-feature-tour.md#post_mortem) run without the debugger, typically on release builds, and you analyze the results after you choose to stop and collect data (for post-mortem analysis).
 
->[!NOTE]
->You can use the non-debugger performance tools with Windows 7 and later. Windows 8 or later is required to run the debugger-integrated profiling tools.
-
-The non-debugger Performance Profiler and the debugger-integrated Diagnostic Tools provide different information and experiences. Debugger-integrated tools show you variable values and let you use breakpoints. Non-debugger tools give you results closer to the end-user experience.
+The Performance Profiler and the debugger-integrated Diagnostic Tools provide different information and experiences. While using the Diagnostic Tools, the debugger shows you variable values and lets you use breakpoints.
 
-To decide which tools and results to use, consider the following options:
+Release build performance numbers in the Performance Profiler are the most precise and accurate. These tools give you results closer to the end-user experience. Typically, this is the preferred method for using the profiling tools. However, there may be scenarios where using the debugger in a debug build may help to narrow down the performance problem, especially if you want to use debugger features such as breakpoints and code stepping.
 
-- Debugger-integrated tool vs. non-debugger tool
-  - 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.
+To help you decide between using the profiling tools in release or debug builds, you might also consider the following:
 
-- 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.
-  - Release builds provide optimizations like inlining function calls and constants, pruning unused code paths, and storing variables in ways that can't be used by the debugger. Performance numbers in the debug builds are less accurate, because debug builds lack these optimizations.
+  - Release builds provide optimizations like inlining function calls and constants, pruning unused code paths, and storing variables in ways that can't be used by the debugger. Performance numbers in debug builds are less accurate, because debug builds lack these optimizations.
+  - In addition to differences between release builds and debug builds, the debugger itself changes performance times, as it does necessary debugger operations like intercepting exception and module load events.
+  - For performance problems caused by CPU-intensive calls, there might be considerable performance differences between release and debug builds. Check to see whether the CPU issue exists in release builds.
+  - External performance problems, like file I/O or network responsiveness issues, won't look much different in a release build or a debug build.
+  - If the problem occurs only with debug builds, you probably don't need to run the tools with release builds.
+  - Some tools, such as the .NET Object Allocation tool, are only available in the Performance Profiler (non-debugger scenarios).
 
-## Collect profiling data without debugging
+## Collect profiling data on release builds
 
-To collect performance data without debugging, you can run the Performance Profiler tools.
+To collect performance data on release builds, run the Performance Profiler tools.
 
 1. With a project open in Visual Studio, set the solution configuration to **Release**, and select **Local Windows Debugger** (or **Local Machine**) as the deployment target.