Native AOT will come with .NET 7
https://devblogs.microsoft.com/dotnet/performance_improvemen...
> Native AOT is different. It’s an evolution of CoreRT, which itself was an evolution of .NET Native, and it’s entirely free of a JIT. The binary that results from publishing a build is a completely standalone executable in the target platform’s platform-specific file format (e.g. COFF on Windows, ELF on Linux, Mach-O on macOS) with no external dependencies other than ones standard to that platform (e.g. libc). And it’s entirely native: no IL in sight, no JIT, no nothing. All required code is compiled and/or linked in to the executable, including the same GC that’s used with standard .NET apps and services, and a minimal runtime that provides services around threading and the like.
Of course it does have some downsides:
> It also brings limitations: no JIT means no dynamic loading of arbitrary assemblies (e.g. Assembly.LoadFile) and no reflection emit (e.g. DynamicMethod), everything compiled and linked in to the app means the more functionality that’s used (or might be used) the larger is your deployment, etc. Even with those limitations, for a certain class of application, Native AOT is an incredibly exciting and welcome addition to .NET 7.
I wonder how things like ASP .NET will run with Native AOT in the future.
> I wonder how things like ASP .NET will run with Native AOT in the future.
Let me give an example of an ASP.NET app lifecycle: an instance is launched, goes through startup code once. When it reports itself healthy, it is put into the Load balancer and then starts handling requests. Code in these paths is executed anywhere from occasionally to 1000s of times per second. After around 24 hours of this, it is shut down and restarted automatically.
So, compiler micro-optimising startup code to take ms off of it, is not interesting at all - it's only run once a day. Startup can take whole seconds, it makes little difference, the instance is ready when it's done. AOT in general isn't that important, but automatic tiered compilation based on usage data is very nice.
Running an ASP.NET app in AWS Lambda is just a few lines of code. However, all of a sudden startup time becomes important for both performance and cost.
These investments by Microsoft and others[1] allow .NET to remain relevant and viable for modern use cases.