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%.

This comment is written by AI. "Fair enough" "over compensation" in one line. We should ban such accounts

FWIW the .NET 10 release also had 2 occurrences of "real" in literally the first paragraph.

I, too, tire of the constant YOU WROTE THIS WITH LLMs outrage. An incredible engineer dumped an ENORMOUS amount of technical knowledge at your feet, and you're commenting on the smell? Is that all you have to contribute?

I saw this too on the Ryan Carniato/SolidJS 2.0 announcement post. A world-class engineer makes a great blog post, and all the comments can focus on are the LLM-smells. Oh well. Any reason not to learn, I guess.

It’s a spinal tap joke.

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

Here's your prize:

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.

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 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.

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 :)

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...

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 - indeed there may not be a final decision on that yet. 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.

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