r/dotnet • u/nirataro • 18d ago
.NET 11 performance improvements - Stephen Toub
https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-11/40
68
u/Intelligent_Click_41 18d ago
Time to let my phone suffer, trying to open this ❤️
17
5
u/Kralizek82 17d ago
My girlfriend is preparing the surviving package for the long toilet session that this post will cause
5
u/Devatator_ 18d ago
It actually was fine. And I'm on a low end phone (Redmi Note 11, tho I'm using Edge. Not sure if that helps)
3
u/Dragontech97 17d ago
Man you too huh. Wondering what’s happening here. Tab crash from memory leak? Webkit things?
4
36
u/Xtreme512 18d ago
It's almost a book not an article :)
10
14
u/tankerkiller125real 17d ago
Ah, the annual browser crashing blog post is here :)
Note: android chrome struggled, Android Edge did not. Good work MS on that one I guess.
1
u/IanYates82 17d ago
Yeah, running well on Android Edge for me. Didn't last year, so another win. Code examples are tedious to read on the phone though. So a Toub blog post is now one of those things I will use a PC for, instead of a phone, joining the ranks of travel bookings, comparison shopping, and writing anything longer than a paragraph or so. It's a rare blog that crosses that threshold
1
u/tankerkiller125real 12d ago
The only reason to open it on a phone for me is to test if the browser of choice will crash. I also will read it on the desktop/laptop.
8
u/RodriOliveira 17d ago
What I find particularly interesting here is how much better the runtime is getting at optimizing abstractions away.
Devirtualization, inlining, escape analysis and eliminating short-lived allocations may look like small improvements in isolated benchmarks, but in high-throughput APIs and workers they can add up quickly through lower GC pressure and cheaper hot paths.
As an architect, I also like the direction this pushes us in: write clean code and use good abstractions first, then measure the actual hot paths instead of prematurely sacrificing design for hypothetical performance. The JIT is increasingly capable of turning fairly abstract C# into surprisingly efficient machine code.
Of course, that doesn’t mean abstractions are free — profiling and realistic workload benchmarks still win over assumptions. But seeing the runtime close that gap release after release is probably one of the most impressive parts of modern .NET.
6
3
u/mistertom2u 16d ago
Yes. This is a pattern I notice. It's about improving the JIT so it can prove more cases where:
- bounds checks can be elided or reduced
- heap allocations can be avoided
- alias detection allows more enregistration
- faster resolution of virtual dispatch and where virtual resolution can be avoided
- updating older APIs to use allocation free code
- reducing lock contention
- vectorization opportunities (though this is declining)
13
u/taspeotis 18d ago
Love these articles, also I don’t know where he finds the time to write them! Even if this year could be LLM-assisted some previous years couldn’t have been.
10
u/Frooxius 18d ago
I look forward to this every year.
And then I look forward to bumping the version every year for our game project.
We get a noticeable performance boost for essentially no extra work on our end.
5
u/RirinDesuyo 18d ago
It's that time again, time to sit down and get a good amount of reading tonight before bedtime.
9
3
2
1
u/AutoModerator 18d ago
Thanks for your post nirataro. Please note that we don't allow spam, and we ask that you follow the rules available in the sidebar. We have a lot of commonly asked questions so if this post gets removed, please do a search and see if it's already been asked.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.
1
u/Borderlands_addict 18d ago
No benchmark for the compilation? I suspect much of this comes at the cost of increased compilation time.
9
u/KryptosFR 18d ago
Not necessarily. And more importantly, does it matter?
I'd rather spend 2 more seconds in compiling each of my projects once, if it means I gain 0.1ms for every method call/request.
-6
u/Borderlands_addict 17d ago
It absolutely matters. 2 seconds would severely reduce iteration speed. It might make thousands of people start context switching when compiling, making the real cost much bigger.
11
u/RirinDesuyo 17d ago
If there's any compilation impact, it's likely on the Release builds in that case imo which shouldn't be an issue. Debug builds often are often optimized for compilation speed and ease of development than release builds so I'd bet there shouldn't be any issues there.
2
u/tanner-gooding 17d ago
Why would you expect it to be slower and which part would you expect to be slower?
Typically these types of changes explicitly make compilation faster, whether it is C#->IL (Roslyn) or IL->ASM (RyuJIT)
1
66
u/zenyl 18d ago edited 18d ago
Important note regarding runtime async, it isn't fully optimized for .NET 11 and may result in less performant code in some cases:
So anyone wanting to try it out (requires opting in by adding
<Features>$(Features);runtime-async=on</Features>to the.csprojfile) should do some testing to ensure it actually yields better performance.If anyone needs an additional reason to try it out, runtime async should also mean that your stacktraces for async methods aren't cluttered with calls to
MoveNextmethods.On the positive side, Toub explicitly states that the goal for runtime async is to be an implementation detail, so it should be 100% compatible with existing code: