Merge pull request #13263 from Mikejo5000/mikejo-br24

Update Copilot information in the VS Profiling case studies

Author: prmerger-automator[bot]

docs/profiling/isolate-performance-issue.md

@@ -1,7 +1,7 @@
 ---
 title: "Isolate a performance issue"
 description: "Learn how to use .NET Counters and the Instrumentation tools to identify, isolate, and resolve performance issues."
-ms.date: 09/20/2024
+ms.date: 10/24/2024
 ms.topic: conceptual
 dev_langs:
   - "CSharp"
@@ -117,30 +117,9 @@ public ActionResult<string> QueryCustomerDB()
 }
 ```
 
-With a little research, we discover that this code is calling an async API without using await. This is the [sync-over-async](https://devblogs.microsoft.com/pfxteam/should-i-expose-synchronous-wrappers-for-asynchronous-methods/) code pattern, which is a common cause of threadpool starvation, and may block threads.
+We do a little research. Alternatively, we can save time and let [Copilot](../ide/visual-studio-github-copilot-extension.md) do the research for us.
 
-To resolve, use await.
-
-```csharp
-public async Task<ActionResult<string>> QueryCustomerDB()
-{
-    Customer c = await QueryCustomerFromDbAsync("Dana");
-    return "success:taskasyncwait";
-}
-```
-
-> [!TIP]
-> Alternatively, we can save time and let Copilot [do the research](#get-copilot-to-research-the-issue) for us.
-
-If you see performance issues related to database queries, you can use the [Database tool](../profiling/analyze-database.md) to investigate whether certain calls are slower. This data might indicate an opportunity to optimize queries. For a tutorial that shows how to use the Database tool to investigate a performance issue, see [Case study: Beginner's guide to optimizing code](../profiling/optimize-code-using-profiling-tools.md). The Database tool supports .NET Core with either ADO.NET or Entity Framework Core.
-
-To get visualizations in Visual Studio for individual thread behavior, you can use the [Parallel Stacks](../debugger/get-started-debugging-multithreaded-apps.md#ParallelStacks) window while debugging. This window shows individual threads along with information about threads that are waiting, threads they're waiting on, and [deadlocks](../debugger/using-the-parallel-stacks-window.md#stack-frame-icons).
-
-For additional information on thread pool starvation, see [Detecting threadpool starvation](/dotnet/core/diagnostics/debug-threadpool-starvation#detecting-threadpool-starvation).
-
-## Get Copilot to research the issue
-
-If we're using [Copilot](../ide/visual-studio-github-copilot-extension.md), we can ask Copilot to research performance issues for us. Select **Ask Copilot** from the context menu and type the following question:
+If we're using [Copilot](../ide/visual-studio-github-copilot-extension.md), select **Ask Copilot** from the context menu and type the following question:
 
 ```cmd
 Can you identify a performance issue in the QueryCustomerDB method?
@@ -149,7 +128,9 @@ Can you identify a performance issue in the QueryCustomerDB method?
 > [!TIP]
 > You can use slash commands such as [/optimize](../ide/copilot-chat-context.md#slash-commands) to help form good questions for Copilot.
 
-In this example, Copilot gives the following code suggestion, the same answer we previously identified by research, along with an explanation.
+Copilot tells us that this code is calling an async API without using await. This is the [sync-over-async](https://devblogs.microsoft.com/pfxteam/should-i-expose-synchronous-wrappers-for-asynchronous-methods/) code pattern, which is a common cause of threadpool starvation, and may block threads.
+
+To resolve, use await. In this example, Copilot gives the following code suggestion along with the explanation.
 
 ```csharp
 public async Task<ActionResult<string>> QueryCustomerDB()
@@ -159,6 +140,12 @@ public async Task<ActionResult<string>> QueryCustomerDB()
 }
 ```
 
+If you see performance issues related to database queries, you can use the [Database tool](../profiling/analyze-database.md) to investigate whether certain calls are slower. This data might indicate an opportunity to optimize queries. For a tutorial that shows how to use the Database tool to investigate a performance issue, see [Case study: Beginner's guide to optimizing code](../profiling/optimize-code-using-profiling-tools.md). The Database tool supports .NET Core with either ADO.NET or Entity Framework Core.
+
+To get visualizations in Visual Studio for individual thread behavior, you can use the [Parallel Stacks](../debugger/get-started-debugging-multithreaded-apps.md#ParallelStacks) window while debugging. This window shows individual threads along with information about threads that are waiting, threads they're waiting on, and [deadlocks](../debugger/using-the-parallel-stacks-window.md#stack-frame-icons).
+
+For additional information on thread pool starvation, see [Detecting threadpool starvation](/dotnet/core/diagnostics/debug-threadpool-starvation#detecting-threadpool-starvation).
+
 ## Next steps
 
 The following articles and blog posts provide more information to help you learn to use the Visual Studio performance tools effectively.

docs/profiling/optimize-code-using-profiling-tools.md

@@ -1,7 +1,7 @@
 ---
 title: "Beginner's guide to optimizing code"
 description: "Learn how to optimize code and reduce compute costs using Visual Studio profiling tools such as the CPU Usage tool, the .NET Object Allocation tool, and the Database tool."
-ms.date: 09/20/2024
+ms.date: 10/24/2024
 ms.topic: conceptual
 ms.custom: "profiling-seo"
 dev_langs:
@@ -137,28 +137,9 @@ foreach (var blog in db.Blogs.Select(b => new { b.Url, b.Posts }).ToList())
 
 This code uses `foreach` loops to search the database for any blogs with "Fred Smith" as the author. Looking at it, you can see that a lot of objects are getting generated in memory: a new object array for each blog in the database, associated strings for each URL, and values for properties contained in the posts, such as blog ID.
 
-We do a little research and find some common recommendations for how to optimize LINQ queries and come up with this code.
+We do a little research and find some common recommendations for how to optimize LINQ queries. Alternatively, we can save time and let [Copilot](../ide/visual-studio-github-copilot-extension.md) do the research for us.
 
-> [!TIP]
-> Alternatively, we can save time and let Copilot [do the research](#optimize-code-with-copilot) for us.
-
-```csharp
-foreach (var x in db.Posts.Where(p => p.Author.Contains("Fred Smith")).Select(b => b.Title).ToList())
-{
-  Console.WriteLine("Post: " + x);
-}
-```
-
-In this code, we made several changes to help optimize the query:
-
-- Added the `Where` clause and eliminate one of the `foreach` loops.
-- Projected only the Title property in the `Select` statement, which is all we need in this example.
-
-Next, we retest using the profiling tools.
-
-### Optimize code with Copilot
-
-If we're using [Copilot](../ide/visual-studio-github-copilot-extension.md), we can ask Copilot to research performance issues for us. Select **Ask Copilot** from the context menu and type the following question:
+If we're using Copilot, we select **Ask Copilot** from the context menu and type the following question:
 
 ```cmd
 Can you make the LINQ query in this method faster?
@@ -167,7 +148,7 @@ Can you make the LINQ query in this method faster?
 > [!TIP]
 > You can use slash commands such as [/optimize](../ide/copilot-chat-context.md#slash-commands) to help form good questions for Copilot.
 
-In this example, Copilot gives the following suggested code changes, similar to our optimized query, along with an explanation.
+In this example, Copilot gives the following suggested code changes, along with an explanation.
 
 ```csharp
 public void GetBlogTitleX()
@@ -184,6 +165,13 @@ public void GetBlogTitleX()
 }
 ```
 
+This code includes several changes to help optimize the query:
+
+- Added the `Where` clause and eliminated one of the `foreach` loops.
+- Projected only the Title property in the `Select` statement, which is all we need in this example.
+
+Next, we retest using the profiling tools.
+
 ## Results
 
 After updating the code, we re-run the CPU Usage tool to collect a trace. The **Call Tree** view shows that `GetBlogTitleX` is running only 1754 ms, using 37% of the app's CPU total, a significant improvement from 59%.