Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Performance Improvements in .NET 7

devblogs.microsoft.com

Post reply on HN
Print view View original

31–40 of 164 posts

Re: Performance Improvements in .NET 7

#31

Post by fabian2k »

romanhn wrote: post #20
fabian2k wrote: post #11

Earlier quoted context omitted.

I think typical ASP.NET applications likely won't use AOT in the near future. There is quite some "magic" in ASP.NET that I suspect won't work out of the box with AOT because it is heavily reflection-based. And while there are solutions for cases like JSON serialization, as far as I understand they require writing different code right now, so it's not automatic. AOT is much, much more interesting for cases where star…

As someone writing a .NET-based API hosted on AWS Lambda, I assure you, startup time matters a ton. I spent a bunch of time getting cold start time down to a semi-reasonable number, but there's still a ton of room for improvement. I for one am very much looking forward to progress on AOT Native.

The "typical" in my comment was meant to take care of that part, I probably should have mentioned this explicitly. AWS Lambda is of course a case where startup time matters a lot, but it still leaves the common problem of ASP.NET that it was designed around a lot of reflection. My understanding is that this simply won't work with AOT out of the box unless you adapt all the places where you use reflection-based code. For example you'd need to use the source generator versions of JSON serialization and the EF Core DbContext in this case, with all limitations those have. But I'm not sure my understanding here is entirely correct or complete.

Re: Performance Improvements in .NET 7

#32

Post by paavohtl »

fabian2k wrote: post #31
romanhn wrote: post #20

Earlier quoted context omitted.

As someone writing a .NET-based API hosted on AWS Lambda, I assure you, startup time matters a ton. I spent a bunch of time getting cold start time down to a semi-reasonable number, but there's still a ton of room for improvement. I for one am very much looking forward to progress on AOT Native.

The "typical" in my comment was meant to take care of that part, I probably should have mentioned this explicitly. AWS Lambda is of course a case where startup time matters a lot, but it still leaves the common problem of ASP.NET that it was designed around a lot of reflection. My understanding is that this simply won't work with AOT out of the box unless you adapt all the places where you use reflection-based code.…

I don't know about ASP.NET, but the post says that Reflection.Emit is not available. Reflection.Emit is a namespace used for runtime code generation; I would assume most other parts of reflection are available, like with previous iterations of AOT support in .NET.

Re: Performance Improvements in .NET 7

#34

Post by tmitchel2 »

fabian2k wrote: post #31
romanhn wrote: post #20

Earlier quoted context omitted.

As someone writing a .NET-based API hosted on AWS Lambda, I assure you, startup time matters a ton. I spent a bunch of time getting cold start time down to a semi-reasonable number, but there's still a ton of room for improvement. I for one am very much looking forward to progress on AOT Native.

The "typical" in my comment was meant to take care of that part, I probably should have mentioned this explicitly. AWS Lambda is of course a case where startup time matters a lot, but it still leaves the common problem of ASP.NET that it was designed around a lot of reflection. My understanding is that this simply won't work with AOT out of the box unless you adapt all the places where you use reflection-based code.…

I think you are correct. The DI container and JSON serialisation are two bigger areas that i suspect would need attention but as you say source generation solves the later and I think there is non reflection DI on the way if not already. I guess you would need to wait for any of the third party assemblies you depend on to allow for no reflection also...still a bit of a wait i think for my use case.

Re: Performance Improvements in .NET 7

#35

Post by ewjt »

SideburnsOfDoom wrote: post #16
giancarlostoro wrote: post #2

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…

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

Serverless.

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.

[1] https://github.com/awslabs/dotnet-nativeaot-labs

Re: Performance Improvements in .NET 7

#36

Post by Salgat »

danparsonson wrote: post #28
XzAeRosho wrote: post #3

I don't follow the .NET ecosystem closely enough, but it feels that releasing a mayor version every year feels like kind of unnecessary? Or if they intend to keep doing this, they should release LTS versions of some kind. It feels kind of scary committing to .NET 7 right now, when in a year, it will be replaced by yet another major version promising ever increasing performance gains... Or is the difference between ma…

I have to agree that it's excessive and I don't understand why they're doing it. Major versions imply breaking changes, which contradicts the assertions of other people here replying that the differences between each version are minor; in that case why not minor version bumps? What's the benefit? The only thing I can think of is that it forces upgrades to new versions of Visual Studio. One immediate problem it create…

Major versions do include breaking changes in some libraries. You usually keep all Microsoft libraries aligned on the same major version to ensure compatibility, and it allows Microsoft to introduce these breaking changes on a regular basis without causing any confusion. If you're on .NET 6, most of your Microsoft nugets are on 6.xx.xx.

Re: Performance Improvements in .NET 7

#37

Post by SideburnsOfDoom »

ewjt wrote: post #35
SideburnsOfDoom wrote: post #16

Earlier quoted context omitted.

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

Serverless. 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. [1] https://github.com/awslabs/dotnet-nativeaot-labs

Serverless is great, but if you want to go that route you should be aware that it is in no way a typical hosted ASP.NET app, and while you can "Run an ASP.NET app in AWS Lambda" with little code, there are are better ways to design a Lambda.

Re: Performance Improvements in .NET 7

#38

Post by pjmlp »

geodel wrote: post #24
giancarlostoro wrote: post #2

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…

Good. Java is doing something similar with Graal Native Image thing. In a way it is funny to see few years back so many people were claiming that heavy CPU/memory usage of JIT based platforms would be even more non-issue in Cloud because one can scale as much they need on demand. And now I see AOT/Slimmed Runtime/Compact packaging are happening largely because of cloud deployments. Seems cloud bills are making impact…

Actually I think it is more competition pressure of languages like Go and Rust than anything else.

I have been using Java and .NET languages for distributed computing for the last two decades, and JIT has always been good enough.

By the way, Google rolled back their AOT compiler introduced on Android 5, and since Android 7 it uses a mix of highly optimized interpreter written in Assembly, a JIT compiler with PGO feedback, and when the device is idle, those PGO profiles are used to only AOT compiler the application flows that matter. On more recent Android versions, those PGO profiles are shared across devices via the Playstore.

On the .NET front, I think the team has finally decided to make front of the whole C++ rulez of WinDev, specially after Singularity and Midori projects having failed to change their mind.

Re: Performance Improvements in .NET 7

#39

Post by bob1029 »

XzAeRosho wrote: post #3

I don't follow the .NET ecosystem closely enough, but it feels that releasing a mayor version every year feels like kind of unnecessary? Or if they intend to keep doing this, they should release LTS versions of some kind. It feels kind of scary committing to .NET 7 right now, when in a year, it will be replaced by yet another major version promising ever increasing performance gains... Or is the difference between ma…

They do have a tick-tock-style LTS approach. Our strategy is to stick with the LTS versions, since we sell software to banks.

The path we are on:

Framework 4.x => .NET Core 2.x => .NET Core 3.1 => .NET 6 (we are here today) => .NET 8

The migration from .NET Core 3.1 to .NET 6 was a total non-event. It was substantially harder for us to go from 2.x to 3.1.

Based upon the current proposals and available documentation, we anticipate our migration from .NET6 => .NET8 will occur with absolutely zero ceremony sometime around Q2 2024.

Re: Performance Improvements in .NET 7

#40

Post by ledgerdev »

giancarlostoro wrote: post #2

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…

It definitely will eventually, probably .net8 timeframe. It will be hard to support so many dynamic features and no doubt will make extensive use of Source Generators. https://docs.microsoft.com/en-us/dotnet/csharp/roslyn-sdk/so...

Anyone have any interest in a small c# aot micro web framework that cold starts up fast (~500ms, vs ~4s for non aot mvc) on serverless containers like google cloud run?

Post reply on HN