Interesting, are there significant performance fixes in the mix?
I always got the impression .net was never particularly performance focused: there were some bits you could use if you wanted to go a bit faster, but it doesn't seem designed from the ground up to be fast, and AoT compilation seems to be perpetually on the back-burner.
Compared to other languages like C++ or Rust, which have been built for speed...
Edit: changed my comment because it was a bit too argumentative.
Saying "built for speed" doesn't really mean much. .NET created the async Task model that other languages adopted and has all kinds of performance related features from Span/Memory APIs to SIMD vector operations.
AOT doesn't have anything to do with performance but helps with startup time and packaging. The .NET JIT now has tiered compilation with secondary passes that optimize hot methods with much more input about the environment, including knowing that it's a hot path. AOT can't do this.
C++ and Rust are faster because they don't have a managed runtime, and Rust's major innovation was moving as much of the memory management into a strong build-time analysis to ensure it's properly access. You can build low-allocation or more manual memory management with .NET and get very similar performance. RavenDB is an example of an fast document database built in .NET Core: https://ravendb.net/
Your comments are surprising since you seem to have experience F# and other languages and yet it sounds like you haven't used any modern .NET version.
> Your comments are surprising since you seem to have experience F# and other languages and yet it sounds like you haven't used any modern .NET version.
Most of the stuff I've written in .net(core) has been in F# and C# (v8) and runtime v3.1. So much pain playing 20 questions with libs whose runtime requirements were thoroughly and widely distributed across all the runtime versions in a quest to get them to co-operate. I guess I'm just not a huge fan of the language in general, it's all a bit too enterprise-design-pattern-clunky-objects and implicit-mutation all the way down, not to mention verbose. I know it's finally, finally getting a half-decent implementation of pattern matching and immutable records, but there's nothing that stands out to me about it that makes me want to use it over literally any other language I know, which I guess is fine as it's primary target is being a "boring" enterprise language, which it excels at.
> AOT doesn't have anything to do with performance but helps with startup time and packaging.
Not sure I'd agree with this: putting code through an optimising compiler like LLVM ahead-of-time means you can apply more performance optimisations for runtime.
> The .NET JIT now has tiered compilation with secondary passes that optimize hot methods with much more input about the environment, including knowing that it's a hot path. AOT can't do this.
That's fair, but if you type-system and language design already tells you everything you need to know, you don't need to wait until code gets hot-enough to swap it in, you just pay the compile-time cost and have it go at peak speed the whole time, my argument here might be veering dangerously close to the 'sufficiently-advanced-compiler' argument hahaha.
> Saying "built for speed" doesn't really mean much. .NET created the async Task model that other languages adopted and has all kinds of performance related features from Span/Memory APIs to SIMD vector operations.
Sure, it's got some fast bits but in my experience very few libraries make any use of them and by default most things are heap allocated, with plenty of pointer-indirection right? Compare that to Rust where far more is stack-allocated and numerous other optimisations and shortcuts get applied so the things you're accessing on the heap still aren't too slow. The async-task model is just a model and has nothing to do with actual run-time performance though right? I had a go playing around with Span when I last wrote stuff in C#, but I found it difficult to do much with it as the compiler either wanted way more things to operate on Span-types (some of which was out of my control) or I needed to do things with iterators that required me to turn it right back into a 'heavyweight' IEnumerable class, which kind of defeated the purpose. Entirely plausible I was using it wrong though.
> RavenDB is an example of an fast document database built in .NET Core: https://ravendb.net/
Ok that's cool, I hadn't heard of this, I'll check it out.
