Ah the traditional browser stress test from the .NET team. :)

Joke aside, yet another interesting read of all little improvements that go across all the runtime, and very much appreciated that they put out the effort to go through this detail level.

Thanks Stephen for this, it is very rewarding to read something very technical that is not AI slop these days.

Runtime async is certainly an interesting development. Really excited to see how this plays out.

I stared at my keyboard for bloody ages and came up with || instead of m.

nob end!

The software has to start clipping the audio above "100%", but I use it regularly in say, VLC, because I might want the volume slightly higher without increasing my whole system volume just to hear a quiet section. I rarely notice any degradation at 150%.

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

True, there are of course exceptions! :D

(Also, other architectures might use J for 'Jump' rather than 'Branch'). I don't make the rules ;)

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.

What I wish more languages did was what the guile optimizer does. There is a source->source optimizer which does inlining, DCE, CSE and partial evaluation.

That is very handy, especially when writing macros. I only have to look at assembly when I want to know about optimizations that are not visible in the source->source optimizer.

If I ever want to know if something is reified (which I never do) I can always look at the ASM.

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.

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.

do you mean NativeAoT? it's mentioned a few times in the post

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.

With Claude I never had that problem. However Claude does not use the pattern by default

I wonder if any of those work alongside Github Copilot (the autocomplete not actual agent).

Because at this point I would do anything if I could get Github Copilot to understand the new language features and stop trying to constantly revert code.

The one specific thing I'm constantly having to deny is Copilot seeing this:

    List<string> items = [];

into this:

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

https://docs.unity.com/en-us/unity-production-pipeline/local...

Always appreciate the continued perf gains. Our existing services just get faster for free, which is a nice win.

Very thorough write up. Clearly a lot of performance improvements across their stack. As if it wasn't detailed/long enough already, I would have loved to see some application-level benchmarks that gave a hint of the cumulative performance gains we should expect.

Saw a noticeable startup time boost on a recent project migration. Always appreciate the continued focus on speed.

We've banned this account for repeatedly posting abusive comments and ignoring our appeals to stop. If you don't want to be banned, you can email us and demonstrate an intention to observe the guidelines. https://news.ycombinator.com/newsguidelines.html

Including the internal Microsoft community

As an ex .NET dev

Just curious.. what language(s) are you using now?

Why do I care if other shops are Windows-only? The language and ecosystem are phenomenal and Linux support is first-class.

It's really the navigations that make EF a problem. I've built a typed object graph database on top of Sqlite that works really well specifically because it's in Sqlite, so the overhead of the 1+N query problem with recursively descending navigations isn't a big problem. But it requires lazy loading and that requires all the navigation to happen inside a single service scope and that makes sequencing some things get difficult (can't just pass the results around willy nilly).

The navigation system in EF is where all of the pain points originate. All of my troubles with getting the migration generator to work are because I'm trying to express rather complex relationships. For example, to store a record representing a property on an object, I need to have two foreign keys from the Properties table to the Types table: one for the type of the property and one for the type in which the property lives. Types themselves have many relationships to other types: their base type, interface types they implement, generic type parameters, constraints on generic type parameters (actually, haven't even implemented that one as is too much).

I'm generally happy with the performance and expressivity of the system I've developed so far, but damn, it came with a lot of pain.

I think for most projects, add an ORM only after you start getting really annoyed and understand what you are trading.

I can't even remember the last time I used MSSQL with .NET. I'm embarrassed that I worked on projects now that were paying huge sums for licenses when .NET works so absolutely well with every other DB.

These days I just use EF with Sqlite on 99% of my projects.

I used .NET for many years with Postgres on a huge project. Honestly, I don't know what you mean. Can you break down "Everything" a little. What is it that expects MSSQL? Who are the thought leaders pushing it?

I'd say Microsoft's revenue related push with .NET these days is to try to subtly nudge you into Azure (where MSSQL is rare and Windows is virtually non-existent). But, I also think they know they will kill .NET if they go overboard with it as the competition is strong.

I do all my dev in .NET on a mac, using Postgres and Sqlite only, so I don't relate to your experience at all. It's dead simple for me and I'm not even that good of a developer.

That is not my experience. Sure, the background of .NET is windows, but in the last decade or so it opened up to other platforms, and so many shops prefer deploying their .NET based applications to linux for multitude of reasons. Along with this comes linux oriented culture. So windows culture is not tied to .NET per se, more so tied to certain shops I would say. Speaking from anecdotal experience, I have no numbers on this :)

Obviously, don't use it if you don't want to and don't have to. It is not worse than Go or Java however which is its only meaningful competition.

Note that Linux often runs on Lenovos and Dells, some of which may be creaky. I guess you are saying you prefer macOS.

It is different. I do nearly 100% of my .NET development on macOS, only dropping into Windows to support .NET Framework users of open-source projects I work on, and we deploy exclusively now on Linux containers. The apps I maintain haven't touched a Windows server in years. My colleagues (and OSS co-maintainers) use a mix of macOS, Windows, and Linux. I use Rider instead of Visual Studio.

The only time I've been forced into a "culture of Windows and creaky Lenovos and Dells" recently was on a Java project. (Anecdotally, of course. Java has a similarly cross-platform culture as a whole.)

I do .NET dev exclusively on a mac completely within Visual Studio Code and it's by far the easiest and most enjoyable framework and ecosystem I've had the pleasure of working in. I couldn't be happier with it.

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.

The writing style is similar to the other articles by the same author. He has been doing this for years. I have no idea what your problem with the actual content is.

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

For anyone who enjoys Stephen Toub’s deep technical articles like this one as much as I do - he also published another post today on migrating the Copilot coding harness from Node.js to Rust. Another great read.

https://github.blog/ai-and-ml/generative-ai/migrating-the-gi...

`AsyncMethodBuilder` is a way to declare async methods that return your own task types. AFAIK it is not supported with the current runtime async, and maybe never will be - it's quite hard to support, I believe.

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.

Disadvantage 2: Writing performant code can no longer be gate kept behind archaic practices, now everyone can just use `var animal = new Dog()` and be done with it.

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.

One of the best perf tests for C# it's to run the Switch emulator against some legal Switch demo game dump.

Please give me a money with 1,0000

Outside of the outstanding optimizations .net has made (plus async runtime), what I really enjoyed was the reworked entry section. Stephen reiterated all the concepts from the past Performance Improvement articles to really showcase the layers of optimization techniques and how the can transform.

As much as Micro$oft is ... subpar, .NET never fails to amaze in the last couple of years. Kudos to the team.

It's long

dotnet has been a pleasure to work with the last few years

Debugger was there, hot reloading was the issue.

Was it? There was only Samsung debugger.