Performance Improvements in .NET 11 (devblogs.microsoft.com)

\m/

I noticed that audio quality begins degrading above 100% (at least if the media is already at high volume), so it really is a useful concept. I'm unsure what Linux distro I'm recalling this from, but it was useful on my little old netbook from college

Not too sure here. I use quite a few commas, too.

I suspect it was done old school: Written by Stephen and passed to a LLM to fill in all those links and other garnish and then passed back for final polish by Stephen. That's how I do my write ups (but generally without the LLM bit for shorter efforts).

This is a long write up, and I'm sure it will have been assisted, but in the right way, and not a sloppy way.

I've dropped several commas before conjunctions, soz!

This is the loudest release of .NET to date(!)

For some people LLM-spotting feels like a sport they need to compete in

Backing you up on this. I smelled LLM and hit cmd+w.

You've never heard/read someone using the same word twice in the same sentence before?

No. If you're a low-level C language programmer then it is useful.

You don’t need to, but if you ever want to really optimise some code, understanding what it turns into on the target CPU really helps. Especially if you know the implications for any particular instruction (cost of memory access, branch prediction misses, etc)

Most devs won’t ever need to know this stuff, but as someone who grew up with computers that could barely do anything without grinding to a halt (8bit computer, 2mhz processor, 32kb of RAM, 20kb of which is for the screen), I still find this stuff useful.

But I am a bit of a performance tuning nerd, so..

Not really, you only need to know you can get at it. One day you might be doing something like processing images or video and you are finding it slow and getting down to this level can be helpful. But it wouldn't necessarily be the first thing you'd look at.

Kinda. I use the `disassemble` function in Common Lisp quite a bit, and I can't work backwards to explain what a function is doing based on the disassembly.

BUT what I can do is see which functions are being inlined, which values are in memory versus in registers, see if things are being boxed and unboxed a lot, see if SIMD is being used, etc.

And more importantly I can compare two versions of a function to see which one looks better by those criteria. It's not perfect, but IME it works really well for guiding optimization.

Assembly is honestly very easy to learn, especially ARM assembly, for the basics (even if whole-program assembly is still difficult). In the worst case, you end up learning something interesting.

Yes. Every professional programmer should be able to read assembly. This culture of ignorance that has been fostered, as seen in sibling comments, is why Notepad now takes 10x as much memory as a full operating system like Windows 95. Application developers should absolutely have an idea of how not to piss away their users' resources. Understanding what you're abstracting away is crucial to that. I promise you it's not even hard. In the 90s every professional programmer understood assembly. It was normal, not some elite hacker language. It can still be normal.

C# takes a lot of different roles. If all you're doing is higher level stuff, say you're only working on a local GUI app where you're waiting on the user 99% of the time, you probably don't need to understand it. But you can also treat C# as more of a low level systems language, maybe you need to optimise some number crunching in a server - and then, as with any systems language, being able to read it may help.

All you could tell from this snippet is that .NET 11 eliminated 2 instructions, one of which is a branch.

You should learn assembly anyway, but it won't make this part any more insightful.

It still exists, it's still a bit quirky because of the way you need to match CPU to binary (e.g. some opcode extensions only existing on some CPUs)

AoT uses the same codegen (mostly) as the JIT so if you see a JIT improvement it's possible NativeAOT/ilc picked up that improvement too.

Unless it's a runtime-only optimization, like guarded devirtualization... there's no straightforward way for an AOT compiler to do that without profiling data.

Native AOT is seeing a lot of use within Microsoft products too. Some bits of the .NET SDK use it, and C# Dev Kit (the C# extension for VS Code) uses it extensively in version 11. It brings a lot of performance to .NET.

Flip side: LLMs have to be very explicitly told to code in "modern" .NET and C# due to lack of representation in the training set.

Case in point: extension members from C# 14 is one that LLMs commonly stumble on and requires an explicit example. It still sometimes says that this is not valid syntax.

    extension(SomeType instance)
    {
        public OtherType DoSomething() { ... }
    }

Agents really struggle on this one for some reason.

Even older releases have a few that I notice LLMs making mistakes on like use of `System.Threading.Lock` over `Object` when locking.

    List<string> items = [];

    List<string> items = new List<string>();

Buildings games in Unity feels like magic with frontier reasoning models.

Assuming you are competent with scene work and the various art pipelines, the rest of the problem is significantly easier now.

I've been using the Unity CLI to run arbitrary C# code against Unity 6 scenes without requiring domain reloads. It uses Roslyn to compile the snippet in a special Unity editor component instead of running the normal compilation pipeline.

The implications for a reasoning model are significant. Domain reloads in my projects can take 10-20 seconds. Compound across 5-10 tool calls and the difference adds up very quickly.

Too bad there’s such a lingering culture of Windows and creaky Lenovos and Dells around it. I’m sure it can be different, but I’m not taking my chances ever again. Simply not worth my sanity.

Now if only they could spend time making Visual Studio 2026 perform up to par.

Just today I created e.g. 100 changes in a file, performed an undo and it rolled back 90 or so of the changes while somehow managing to keep the 5 at the start and the 5 at the end.

looks like a large chunk of this was written by claude though :(

the technical parts are fresh as ever but the writing style is awful, man

Really? I got bored throughout the 7 paragraph (or whatever number) in unrelated introduction.

I thought the exact opposite a few lines in, and that's a shame because I'm genuinely interested. But it was unreadable.

I'm not sure what you mean exactly?

Here is the "Runtime async" section: https://devblogs.microsoft.com/dotnet/performance-improvemen...

I'm not sure if this will surface as an "enabled by default" feature in .NET 11, but it is an active area of work that will arrive sooner or later.

actually this is likely just as performant as the "Ugly but fast" code from the famous talk. After all, this is just branching on GetType() == typeof(Dog) which is presumably boiling down to an integer comparison. This roughly the same as the following C code:

    void speak_generic(void* animal, int type_id) {
      if (type_id == DOG) {
        dog_speak((Dog*)animal);
      } else {
        dispatch_speak_vtable(animal);
      }
    }

Advantage 1: You don't have to maintain this logic (its automatic), so you won't get weird cases if you forget to update all your switches everywhere, and/or you get weird fallthrough logic and footgun yourself in C.

Advantage 2: You still get the flexibility of the vtable if you need it (for the case the type is chosen at runtime at not known). But for 90% of cases, its just as fast as the ugly C code.

Disadvantage 1: Losing a smug sense of superiority because you eschew abstractions and prefer writing verbose error-prone switch statements over clean easy to understand code.

You can always just not use OOP. C#'s tooling for functional programming and C-style programming is really good, thanks to stuff like statics on interfaces or spans.

Oh yea...

My reading was like this:

- "how much things they postpone to put into v11 ?"

- "moving to stack is faster then heap"

- so.. why they just not use multiple stacks ?? ring buffers are just progressive stack but plain stack is just pointer moving... Hmm, but what is usecase except recursive function calling ?

- ok, I read that articele

- what ? it's just a first part ??

- async thingies

- "state machines looks like that"

- aha, always wanted to konw that, thank you Microsoft! Wait, what?? What I just said ?? That really happened?

- scroll, then scroll more some asm code, maybe I read it later

- something interesting, don't remeber now

- next morning coffee time: O, I have some more to read, maybe I can learn something more ?

- ok, work time but probably will finish reading later today

So it is realy nice article. I learned how to do old-school async wrappers in plain C :)

The situation about debugger didn't change really. https://github.com/dotnet/core/issues/505 At least they didn't close the issue...

https://isdotnetopen.com/ has a good list of "dramas" questioning if .NET is truly open. At least there are not many new dramas from Microsoft...

For me it's not that big of a deal that some parts are not open. At least we have good competition (Microsoft (Visual Studio, VsCode c# Dev Kit) vs Jetbrais (Rider, VsCode + recent "Resharper for VsCode" extension.) that prevents one party to mess up something big.

C# Dev Kit is also receiving huge performance improvements with .NET 11. It's available now on the pre-release version of the extension, if you want to check it out. Some details in the .NET Unboxed video here https://m.youtube.com/watch?v=5fvi7m1QxIY