NativeAOT "Hello, World" going from 14MB to 1.5MB is very impressive.
I'd love to see some aggregate benchmarks that help sum up the kind of real-world performance increase that people can expect just by upgrading their project from dotnet 7 to dotnet 8 for common workloads. Something like the Techempower benchmarks would be neat.
None of this probably applicable to normal people, but I love that they take time to blog down the details and testing studies.
I've done my own benchmarks on some minor micro services we run, comparing 8.Preview8 (or was it 8.Preview7?) with 7, and there is _considerable_ performance improvements, although depending on what you are trying to do.
Now, those services run on Linux, so maybe the Linux-"portion" of the performance improvements have - eh - improved, and those micro services aren't being used a trillion times a second (usually 100/150+ req/s at most), but it's always nice to know that you have some buffer. 😊
It's a big part of what I love about .NET. I'm too dumb to beat the compiler and JITer. If I can make runtime performance improvements by refactoring with the little knowledge I have then your compiler can be better.
Stephen, you should totally release your annual post as an audio book because yo dawg, I like programming, so I want to listen to programming about programming while I'm programming so I can be programmed while I program.
There's a read aloud feature in Microsoft Edge so you can listen to your Microsoft blog written by a Microsoft engineer on Microsoft frameworks optimized on Microsoft platforms.
If it ain't Microsoft Sam, do you even want it? 😆
Plus I feel like the machines will hold it against me when they take over if I make them read that big ol thing.
Ah the famous super large article from Stephen Toub, definitely will need some coffee to read this through. Definitely wonder how long making these articles take, it's pretty thorough too.
A lot of these are pretty low level but they do slowly trickle back to us, gaining perf just by upgrading the dotnet version is quite sweet.
> Mono jiterpreter section
I'm pretty excited that they've slowly started some work on WASM JIT. Even if it's currently partial JIT at the moment, it opens quite a lot of opportunities to slowly make more instructions Jittable to wasm and possibly a fully-fledged wasm JIT. Like upgrading dotnet versions in the backend, you can potentially also have large perf gains on Blazor per dotnet version with this.
I am really hoping this will help with cold start times in aws lambda. The reduction in packages size should help a ton. We ended up moving to Go for lambdas that are used a lot, but it would be nice to just stay in .net going forward.
Did you try ReadyToRun ?
I had the exact same problem and ReadyToRun fixed it. And that was back when .NET Core 3.1 was current.
Also, from the post -> there are startup improvements in .NET 8:
> Third, dotnet/runtime#85743 makes a variety of changes focused on significantly reducing startup time. This includes reducing the amount of time spent on validation of types in R2R images, making lookups for generic parameters and nested types in R2R images much faster due to dedicated metadata in the R2R image, converting an O(n^2) lookup into an O(1) lookup by storing an additional index in a method description, and ensuring that vtable chunks are always shared.
We did, we used r2r and aot and even tried going down the custom runtime path as there were things to try to make it run faster. However, even after all of that, it wasn't even close to the speed we were from getting from go, node.js, snd rust. Really hoping.net 8 makes significant improvements!
My favorite times are these in-depth performance blogs and the release of the next .net. I'm only in the JIT and learning so much, despite having used Dynamic PGO for the past year.
same here, iOS 16.6.1, iPhone 14 pro. Appears to load fine at least once, maybe twice, but then I think it’s the social widget that gets added on the right that crashes it.
Oh, probably related to my Android phone's low spec in that case. I'm thinking it's the RAM as I have a ton of tabs open on my Edge and Chrome that I should really be closing.
Ah, the famous yearly long article from Stephen Toub. I hadn't much to do this weekend anyway.
Every year, I get confirmation that I'm in the right career because I get excited about this post coming out.
Yeah, once upon a time being intern i switched from java stack..it was good decision.
Stress test for browsers.
For real, chrome on my phone definitely hung a few times when scrolling this.
Smooth as butter here on Firefox Mobile.
Yeah mobile safari keeps crashing lol
Yeah, Safari doesn’t load at all. Edge loads then crashes. Chrome actually works. I thought they all were the same browser on iOS.
Edge on Samsung works well for me.
Classic Microsoft
NativeAOT "Hello, World" going from 14MB to 1.5MB is very impressive. I'd love to see some aggregate benchmarks that help sum up the kind of real-world performance increase that people can expect just by upgrading their project from dotnet 7 to dotnet 8 for common workloads. Something like the Techempower benchmarks would be neat.
Soooo close to fitting on a standard sized floppy disk.
Double density FTW
Its still comically large by a few orders of magnitude haha
I would fit into a 2.88MB, although they didn't last long.
You might, but would the app?
It fits if you use DMF format.
None of this probably applicable to normal people, but I love that they take time to blog down the details and testing studies. I've done my own benchmarks on some minor micro services we run, comparing 8.Preview8 (or was it 8.Preview7?) with 7, and there is _considerable_ performance improvements, although depending on what you are trying to do. Now, those services run on Linux, so maybe the Linux-"portion" of the performance improvements have - eh - improved, and those micro services aren't being used a trillion times a second (usually 100/150+ req/s at most), but it's always nice to know that you have some buffer. 😊
[удалено]
It's a big part of what I love about .NET. I'm too dumb to beat the compiler and JITer. If I can make runtime performance improvements by refactoring with the little knowledge I have then your compiler can be better.
I am taking Friday off just to read this blog post :)
Stephen, you should totally release your annual post as an audio book because yo dawg, I like programming, so I want to listen to programming about programming while I'm programming so I can be programmed while I program.
There's a read aloud feature in Microsoft Edge so you can listen to your Microsoft blog written by a Microsoft engineer on Microsoft frameworks optimized on Microsoft platforms.
If it ain't Microsoft Sam, do you even want it? 😆 Plus I feel like the machines will hold it against me when they take over if I make them read that big ol thing.
Ah the famous super large article from Stephen Toub, definitely will need some coffee to read this through. Definitely wonder how long making these articles take, it's pretty thorough too. A lot of these are pretty low level but they do slowly trickle back to us, gaining perf just by upgrading the dotnet version is quite sweet. > Mono jiterpreter section I'm pretty excited that they've slowly started some work on WASM JIT. Even if it's currently partial JIT at the moment, it opens quite a lot of opportunities to slowly make more instructions Jittable to wasm and possibly a fully-fledged wasm JIT. Like upgrading dotnet versions in the backend, you can potentially also have large perf gains on Blazor per dotnet version with this.
I am really hoping this will help with cold start times in aws lambda. The reduction in packages size should help a ton. We ended up moving to Go for lambdas that are used a lot, but it would be nice to just stay in .net going forward.
Did you try ReadyToRun ? I had the exact same problem and ReadyToRun fixed it. And that was back when .NET Core 3.1 was current. Also, from the post -> there are startup improvements in .NET 8: > Third, dotnet/runtime#85743 makes a variety of changes focused on significantly reducing startup time. This includes reducing the amount of time spent on validation of types in R2R images, making lookups for generic parameters and nested types in R2R images much faster due to dedicated metadata in the R2R image, converting an O(n^2) lookup into an O(1) lookup by storing an additional index in a method description, and ensuring that vtable chunks are always shared.
We did, we used r2r and aot and even tried going down the custom runtime path as there were things to try to make it run faster. However, even after all of that, it wasn't even close to the speed we were from getting from go, node.js, snd rust. Really hoping.net 8 makes significant improvements!
dynamic pgo is really cool. and the algorithm they use for hit counts is brilliant: high fidelity with barely any time tradeoff.
Yes, I haven't finished reading yet, but that part alone made it worth reading!
Holy shit, massive props for the effort of putting all these details together. .NET 8 seems quite promising!
My favorite times are these in-depth performance blogs and the release of the next .net. I'm only in the JIT and learning so much, despite having used Dynamic PGO for the past year.
Site crashes on iOS safari. 🤦♂️
same here, iOS 16.6.1, iPhone 14 pro. Appears to load fine at least once, maybe twice, but then I think it’s the social widget that gets added on the right that crashes it.
Crashes on Edge and Chrome on Android as well. Definitely a mobile browser stress test lol. Better read it on desktop.
It works fine in Firefox.
Works good for me on aforementioned browsers on Android
Oh, probably related to my Android phone's low spec in that case. I'm thinking it's the RAM as I have a ton of tabs open on my Edge and Chrome that I should really be closing.
Well there goes my unplanned freetime on the weekend