Performance Improvements in .NET 7 • Hacker News Board

Re: Performance Improvements in .NET 7

#41

Post by smcl » Wed, Aug 31, 2022, 3:01 PM UTC

ochronus wrote: post #8

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 have an excellent track record of not breaking compatibility, most updates are drop-in & forget (unless you want to utilize new lang/runtime features)

I recall a few bumpy bits in the various upgrades from 1.0 to 2.2 - they reworked quite a few areas such that updating the .NET Core version required changing your code. They provided good documentation and migration guides, but they did definitely break things along the way.

Re: Performance Improvements in .NET 7

#42

Post by ledgerdev » Wed, Aug 31, 2022, 3:10 PM UTC

SideburnsOfDoom wrote: post #27

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.

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.

I would like to host .net based api on google cloud run and azure container apps, which often will go to sleep after about 10 minutes without a request, so cold start time do matter quite a bit. I've done pretty extensive testing and see ~4-7 second cold starts with classic non aot mvc versus ~500ms with natively compiled golang/.net.

The reality of the cloud is that sleep & cold starts are very common and in fact necessary to run efficient systems. Half a second is acceptable but 4+ seconds is not and so aot is very important for future apps.

Re: Performance Improvements in .NET 7

#43

Post by ledgerdev » Wed, Aug 31, 2022, 3:13 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.

The good news is that .net7 aot supports console apps so lamdas can already be native aot. Json serialization was a concern of mine, but it was surprising easy to get working with very minor changes in the call. If I were building lambdas would move it asap.

Re: Performance Improvements in .NET 7

#44

Post by geodel » Wed, Aug 31, 2022, 3:14 PM UTC

pjmlp wrote: post #38

geodel wrote: post #24

Earlier quoted context omitted.

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

Nowadays Go is working on a PGO solution, so there is that.

I don't disagree but kinda doubt that new upstart languages with single digit market and mindshare in enterprise space would force .net /JVM behemoth to do anything. Forget Go, places I work would not know a single new thing beyond Java 1.7 or latest Java 1.8. But they have stood up a dozen cloud teams doing every buzzword you can hear about cloud.

So unless finance guys ask tough questions about rising Amazon billing IT wouldn't care if their SpringBoot crapola take 2GB of RAM or 32GB.

Re: Performance Improvements in .NET 7

#45

Post by bob1029 » Wed, Aug 31, 2022, 3:14 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…

I don't try to keep up with absolutely everything. I've been to this particular buffet for a really long time and have developed tastes for certain things.

For instance, I recognize AOT is elegant in theory, but I also notice it's a difficult thing to get right and has certain tradeoffs. Especially, for a complex application that may need to use legacy APIs. As a consequence, I have mostly avoided this in favor of focusing on other areas that do seem to deliver additional value for our product (and my side-projects). Examples of these being intrinsics (SIMD), UTF8 text/serializer, file I/O and more advanced GC techniques.

Ultimately, it's a matter of experience to know when you should and should not chase a particular rabbit. My general policy right now is to observe the new shiny while it's in the odd-version, and then wait to see how it shakes down by the time the LTS comes around. You almost never want to try to grab a Microsoft-branded rabbit upon the very first sighting.

Re: Performance Improvements in .NET 7

#46

Post by davidfowl » Wed, Aug 31, 2022, 3:15 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…

We've been experimenting with NativeAOT for years with ASP.NET Core (which does runtime code generation all over the place). The most promising prototypes thus far are:

- https://github.com/davidfowl/FasterActions - https://github.com/davidfowl/uController

They are source generated version of what ASP.NET does today (in both MVC and minimal APIs). There are some ergonomic challenges with source generators that we'll likely be working through over the coming years so don't expect magic. Also its highly unlikely that ASP.NET Core will not depend on any form of reflection. Luckily, "statically described" reflection generally works fine with NativeAOT.

Things like configuration binding, DI, Logging, MVC, JSON serialization all rely on some form of reflection today and it will be non-trivial to remove all of it but we can get pretty far with NativeAOT if we accept some of the constraints.

As of right now, we're trying to make sure "motivated people" can play with it, but it's not something that is supported by ASP.NET Core or EF at the moment. https://github.com/dotnet/aspnetcore/pulls?q=is%3Apr+nativea...

PS: Some of the challenges https://github.com/dotnet/aspnetcore/issues/42221

Re: Performance Improvements in .NET 7

#47

Post by mikece » Wed, Aug 31, 2022, 3:17 PM UTC

kryptiskt wrote: post #10

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…

Every other release is an LTS release, with three years of support. .NET 6 was one so this won't be. They are pretty good about backwards compatibility, upgrading .NET Core and .NET hasn't been a big deal so far.

I have an issue with calling three years "long term" support. Most companies won't update to the new LTS for 9 to 12 months in order for any issues to be ironed out, so that means you get only 24 to 27 months on the LTS. Between CVEs and upgrading to dotnet6 before the end of life on dotnet3.1 most of my coworkers and I have gotten almost no new coding done on our applications this summer (and this was after a three month blitz to get all of our code up to dotnet3.1 ahead of the dotnet2.1 end of life less than a year ago). As long as the LTS doesn't introduce a lot of breaking changes then it's not that big of a deal but when you have to refactor and rewrite non-trivial chunks of code this gets to be really wasteful.

Re: Performance Improvements in .NET 7

#48

Post by fabian2k » Wed, Aug 31, 2022, 3:20 PM UTC

https://devblogs.microsoft.com/dotnet/performance_improvemen...

This is a really interesting, or rather terrifying part of that blog post. I thought I had a reasonably good knowledge about typical performance mistakes in .NET, but I never heard about this particular one.

If I understand it right, initializing a fresh JsonSerializerOptions object before each call to Serialize/Deserialize in System.Text.Json is incredibly expensive. It essentially disables the cache and means the serializer analyzes this case fully every time. And this is more on the order of 100x as expensive than using the cached version, so not a trivial amount.

Re: Performance Improvements in .NET 7

#49

Post by francisofascii » Wed, Aug 31, 2022, 3:26 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…

Fortunately the upgrade path has not been too bad once you get to .NET Core. Usually one time changes to your Program.cs and Startup.cs files. The Top-Level statements addition is pretty jarring at first, but a cool addition. I did run into a breaking change from .NET 5 to 6 with an Encryption library not working right. But most everything else just works when upgrading. If it was just .NET additions life would be fine. It is the front-end churn that causes real stress. AngularJS, TypeScript, Angular, React, Blazor, WebPack, Vite, etc.

Re: Performance Improvements in .NET 7

#50

Post by TillE » Wed, Aug 31, 2022, 3:28 PM UTC

SideburnsOfDoom wrote: post #5

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 should release LTS versions of some kind. Uh? .NET 6 is the current LTS version. 8 will be the next. https://dotnet.microsoft.com/en-us/platform/support/policy I don't comment on Java or Python platform versioning policies because, like you with .NET, "I don't follow the ecosystem closely enough" so I don't have anything meaningful to say about it. > It feels kind of scary committing to .NET 7 right now .. Or…

One of the weirder HN tropes is being upset that new software continues to be released, or that languages get updated with new features.

I've so rarely seen truly major breaking changes that require substantial effort in updating your own code. Like, the Python 2->3 transition is notable because it's unusual.