A hot path in SharpZipLib was making 40,000 delegate invocations where 10,000 would do. That is the kind of finding that usually costs you an afternoon: collect a trace, squint at a call tree, form a theory, write a microbenchmark, change one line, run it again, and hope the number moves in the right direction. In the demo Microsoft used to introduce Visual Studio's new Copilot Profiler Agent, that entire loop collapsed into a single prompt. The agent ran the benchmark, proposed the change, applied it, and re-ran to confirm about 24% better throughput with the delegate overhead gone.
I've spent enough time in the Performance Profiler to be skeptical of anything that promises to read a flame graph for me. After going through the announcement and the reference docs, I think the skepticism is aimed at the wrong thing. The interesting part of this agent isn't that it interprets profiling data. It's that it automates the measurement loop most of us skip.
What actually happens when you type @profiler
The agent lives inside Copilot Chat in Visual Studio 2026 (currently Insiders), and you reach it two ways. Tag it directly, or enable it under the chat tool picker and let agent mode route to it from plain language:
@Profiler Please evaluate the performance of this code
Why is my frame rate dropping?
From there it is not a chat toy that pattern-matches your source. It asks permission to run the profiler, and on confirmation it drives the real diagnostics pipeline:
- It reads the code and picks a measurable entry point.
- It adds BenchmarkDotNet to the project — package references and all — and writes benchmarks into a new file if none exist. Where a suitable unit test or benchmark already covers the hot path, it reuses that instead.
- It runs the comparison, dumping results into the Output window under Diagnostics Hub and producing a real
.diagsession report you can open yourself.
- It summarizes what it found, proposes fixes, and — once you accept — re-runs to validate the delta.
The scope today is deliberately narrow: high CPU usage and .NET object allocations, plus .NET Counters for ASP.NET. That is enough to cover the two questions people actually bring to a profiler, and Microsoft says more analysis types are coming.
The loop, not the flame graph
Here is the reframing that made it click for me. The friction in performance work was never really "I can't read the profiler." It was the tax on every step around the reading. Setting up a representative benchmark is annoying. Wiring BenchmarkDotNet into a project that never had it is annoying. And crucially, re-measuring after a change is the step people quietly drop, which is how "optimizations" ship that make things slower.
The agent's contribution is that it refuses to skip the re-measure. Every suggestion arrives attached to a before/after number, because it generated the harness that produces that number. That is a different value proposition than "AI explains your call tree." It is closer to a junior engineer who is religious about the scientific method and never forgets to run the control.
The docs walk through this on an Entity Framework Core example that is worth reading because the fix is unglamorous and correct. The seeded query pulls every row into memory, then chains redundant ToList() calls:
var inefficient = all
.Where(p => p.Age > 50)
.ToList()
.Where(p => p.City.StartsWith("C"))
.ToList()
.Select(p => p.Name)
.Distinct()
.OrderBy(n => n)
.Take(10)
.ToList();
The agent measured a roughly 33% efficiency gain from collapsing that into a single translated query with AsNoTracking() and no intermediate materialization:
var optimized = db.People
.AsNoTracking()
.Where(p => p.Age > 50 && p.City.StartsWith("C"))
.Select(p => p.Name)
.Distinct()
.OrderBy(n => n)
.Take(10)
.ToList();
Nothing here is a revelation to a senior .NET developer. The point is that it was found by measurement, verified by re-measurement, and handed over as a diff you approve line by line rather than a paragraph of advice you have to go act on.
Where it earns trust, and where you still own the call
The credibility argument Microsoft makes is that the agent has already landed real pull requests against CSVHelper, NLog, and Serilog — mature, performance-conscious libraries whose maintainers do not accept hand-wavy patches. One of their principal engineers noted it surfaced a .NET duck-typing optimization that experienced engineers had missed. That is a meaningful signal, because those codebases are exactly where cheap wins have already been taken.
But the same mechanism that makes it trustworthy is the thing to watch. The agent optimizes what it can measure, and when there is no benchmark it writes one. A synthetic microbenchmark is only as honest as its assumptions about inputs, warmup, and workload shape. An agent that reduces 40,000 delegate calls to 10,000 has genuinely improved a real measurement; an agent that speeds up a benchmark exercising an unrepresentative input has improved nothing that ships. BenchmarkDotNet handles the statistical rigor — warmup, iterations, variance — but it cannot tell you whether the scenario is the one your users hit.
Instead of raw data, you now get an AI partner that not only points out the real bottlenecks but also explains what's going on.
That framing is right, with one edit: the bottleneck is only "real" relative to the workload you fed it. Reading the generated benchmark to confirm it exercises the path that matters is now the highest-leverage thing a human does in this loop. It is also the one step the agent cannot do for you, because only you know what production actually looks like.
The takeaway
Treat the Profiler Agent as a way to make measurement cheap, not as a way to make judgment optional. The next time you suspect a hot path but can't justify the afternoon it takes to prove it, that calculus has changed — the setup cost is now a sentence. Spend the time you save reading the benchmark it generates instead of the flame graph it read, and reject any fix whose measured scenario you can't vouch for. The agent closes the loop; you still decide whether the loop was pointed at the right thing.
Sources: Democratizing Performance: The Copilot Profiler Agent in Action on Real Code (Visual Studio Blog), Profile with GitHub Copilot Profiler Agent (Microsoft Learn)