Performance Improvements in .NET 7 • Hacker News Board

Re: Performance Improvements in .NET 7

#21

Post by tmitchel2 » Wed, Aug 31, 2022, 2:21 PM UTC

fabian2k wrote: post #11

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

Using ASP.NET with AWS Lambda or any other FAAS is a concrete scenerio. Startup time for that is critical.

Re: Performance Improvements in .NET 7

#22

Post by hardware2win » Wed, Aug 31, 2022, 2:22 PM UTC

spaetzleesser wrote: post #6

On the one hand it's cool that they are improving but how do people keep up with all these additions? I find this really hard. Seems a lot of the changes are new stuff which you have to evaluate and see how they could actually be used productively. For example a while ago I tried the new nullable stuff and while in theory it looks straightforward it turned out to be very difficult to use nullable with existing APIs a…

>On the one hand it's cool that they are improving but how do people keep up with all these additions? I find this really hard.

Very often they improve things in a way that you'll get an improvement regardless of whether you are aware

E.g linq, collections, regexes, etc.

Re: Performance Improvements in .NET 7

#23

Post by tmitchel2 » Wed, Aug 31, 2022, 2:22 PM UTC

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.

Lol snap

Re: Performance Improvements in .NET 7

#24

Post by geodel » Wed, Aug 31, 2022, 2:23 PM UTC

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 in places where enterprise cloud architects were running amok with everything micro service deployments.

Re: Performance Improvements in .NET 7

#25

Post by pjmlp » Wed, Aug 31, 2022, 2:23 PM UTC

spaetzleesser wrote: post #6

On the one hand it's cool that they are improving but how do people keep up with all these additions? I find this really hard. Seems a lot of the changes are new stuff which you have to evaluate and see how they could actually be used productively. For example a while ago I tried the new nullable stuff and while in theory it looks straightforward it turned out to be very difficult to use nullable with existing APIs a…

We don't really keep up.

I read with interest all these articles, and then go back coding our LOB stuff in .NET Framework 4.7.2 and similar.

On the Java side, I am finally confident that all our servers have at least Java 11 on them.

Only on private stuff do I happen to enjoy latest versions.

Re: Performance Improvements in .NET 7

#26

Post by jabart » Wed, Aug 31, 2022, 2:28 PM UTC

spaetzleesser wrote: post #6

On the one hand it's cool that they are improving but how do people keep up with all these additions? I find this really hard. Seems a lot of the changes are new stuff which you have to evaluate and see how they could actually be used productively. For example a while ago I tried the new nullable stuff and while in theory it looks straightforward it turned out to be very difficult to use nullable with existing APIs a…

Nullable's have been around for at least a decade and before .Net core existed? Are you thinking of the NotNull attribute argument checking instead(Likely the wrong term here)? Any change in a data type to an existing API or code will always be tough and a lot of work. Maybe an in32 to a in64 being the exception.

Library developers are looking at these and following them to make enhancements. Developers working on business apps get the automatic performance improvements of these changes and the library dev changes to improve performance and allocations. I personally quickly go over these so when I get into a performance issue I have a little bit to know where to go find more information.

Re: Performance Improvements in .NET 7

#27

Post by SideburnsOfDoom » Wed, Aug 31, 2022, 2:29 PM UTC

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.

As someone writing a .NET-based API hosted on AWS Lambda, your case is quite different to a "typical ASP.NET hosted application", that can run for days between restarts.

Re: Performance Improvements in .NET 7

#28

Post by danparsonson » Wed, Aug 31, 2022, 2:30 PM UTC

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 creates is with recruitment - between 2019 and 2021 we went from .NET Core 3.0, through 3.1, .NET 5, and now .NET 6, and suddenly in the space of one job I went from up-to-date to 'legacy CV'.

Re: Performance Improvements in .NET 7

#29

Post by fnord123 » Wed, Aug 31, 2022, 2:32 PM UTC

tmitchel2 wrote: post #23

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.

Lol snap

No, snap startups have an even worse startup time.

Re: Performance Improvements in .NET 7

#30

Post by ewjt » Wed, Aug 31, 2022, 2:33 PM UTC

spaetzleesser wrote: post #6

On the one hand it's cool that they are improving but how do people keep up with all these additions? I find this really hard. Seems a lot of the changes are new stuff which you have to evaluate and see how they could actually be used productively. For example a while ago I tried the new nullable stuff and while in theory it looks straightforward it turned out to be very difficult to use nullable with existing APIs a…

Can you name other development platforms of similar scale/depth that don’t have this issue?

Compared to the whirring treadmill of frontend web development, I find .NET to be pretty easy to keep up with. Good IDEs (ReSharper or Rider) really help with the new language features (which are opt-in).

Outside of that, the ecosystem is large enough that there are quality blogs/articles/podcasts to stay current without sinking a ton of time into doing so.