David Kean

Visual Studio 2026 represents about a year's worth of work across the Visual Studio team. If you haven't tried it, head over to visualstudio.microsoft.com/insiders/ to download it - it will install alongside Visual Studio 2022 so you can continue to use both if you like.

We've been working for a while on a vision of what Visual Studio looks like in the future, and first insiders build of 2026 represents one of our first steps towards that. On top of being gorgeous with its modern Fluent UI, this build one of the fastest releases we've released, with more to come.

. @vscode.dev What happened here, I find it super hard to find the commands I actually want to click on this. 5 ways to split, probably unneeded?

One time during .NET Core early days, we were having a remote meeting with Fowler and another colleague of his. This was in the days when video meetings were a bit unusual. His colleague completely forgot he was on video and had a reaction like this to something I said.

We added a feature to Visual Studio to automatically detect when it uses an unusual amount of CPU. After 20 mins of continuous CPU across all threads combined (and the machine has been sampled), we capture a short trace.

On machines with high core count, there was just too much contention, resulting in a degradation of the scenario in a way that burned more CPU due to threads being taken on and off the CPU than actually "real work". This was a real issue, and CPU tracing was vindicated!

We added a feature to Visual Studio to automatically detect when it uses an unusual amount of CPU. After 20 mins of continuous CPU across all threads combined (and the machine has been sampled), we capture a short trace.

But here I could see this lock consuming CPU due to Windows context switching. This is the overhead of moving threads on and off the CPU. It's usually a tiny overhead in the scheme of things, but here I could not only see it showing up, but i could see 90% of the CPU used was just context switching.

We added a feature to Visual Studio to automatically detect when it uses an unusual amount of CPU. After 20 mins of continuous CPU across all threads combined (and the machine has been sampled), we capture a short trace.

I went to close the bug and agree that this was actually a legitimate use case and privately lament that the "always right" of CPU tracing no longer held. But then I noticed something...

We added a feature to Visual Studio to automatically detect when it uses an unusual amount of CPU. After 20 mins of continuous CPU across all threads combined (and the machine has been sampled), we capture a short trace.

That is until today. I came across a resolved issue that had been marked as by design; this code legitimately spanned itself across a lot of cores with the intention of getting through this user triggered process really quickly.

We added a feature to Visual Studio to automatically detect when it uses an unusual amount of CPU. After 20 mins of continuous CPU across all threads combined (and the machine has been sampled), we capture a short trace.

This doesn’t stop VS devs and extension authors, however, from trying to convince me that their feature is special and that they intentionally use that much CPU for their algorithm.

We added a feature to Visual Studio to automatically detect when it uses an unusual amount of CPU. After 20 mins of continuous CPU across all threads combined (and the machine has been sampled), we capture a short trace.

It's a nice little system and resulted in a release to release decrease in CPU usage across the board for Visual Studio. It also captured some bugs that have been around forever that we would never have seen, let alone fixed without it having captured the issue.

We added a feature to Visual Studio to automatically detect when it uses an unusual amount of CPU. After 20 mins of continuous CPU across all threads combined (and the machine has been sampled), we capture a short trace.

I spend my day breaking builds, so thankful that these folks are there to pick up the pieces, including @kirillosenkov.com himself who has written the best tool to diagnose them msbuildlog.com!