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

61–70 of 164 posts

Re: Performance Improvements in .NET 7

#61

Post by pjmlp »

geodel wrote: post #44
pjmlp wrote: post #38

Earlier quoted context omitted.

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

The new upstart languages are where the younger generations are, that is why you see .NET doing all those changes to make rolling an Hello World website as easy as doing it in Go, with global usings, single file code, simplified namespaces and naturally AOT.

Re: Performance Improvements in .NET 7

#62

Post by Wohlf »

cyral wrote: post #57
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…

The updates from .NET Core 2 to .NET Core 6 have taken me maybe an hour of combined work across many years. Each major version has barely any breaking changes if any.

Yeah it's pretty much just new features, and you can stick to the LTS releases.

Re: Performance Improvements in .NET 7

#63

Post by ThunderSizzle »

Salgat wrote: post #36
danparsonson wrote: post #28

Earlier quoted context omitted.

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.

It gets really weird when you have one dependency including .NET 6 version, and another including .NET 5, since they sometimes rework nuget packages with how many Microsoft.Extensions they have now.

Re: Performance Improvements in .NET 7

#64

Post by ThunderSizzle »

smcl wrote: post #41
ochronus wrote: post #8

Earlier quoted context omitted.

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.

I recall most developers didn't jump from 472 to core 1 since this was thr expectation.

I barely started touching core until core 3, and really started checking out .net 5.

Re: Performance Improvements in .NET 7

#65

Post by trevorishere »

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…

SharePoint, as an example, can take 1+ minutes to JIT.

Re: Performance Improvements in .NET 7

#66

Post by lvass »

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 just can't help laughing profusely whenever I see MS doing a Native something. Don't you folks remember Native HTML5?

https://www.youtube.com/watch?v=9mXe9nRiPHI

Re: Performance Improvements in .NET 7

#67

Post by jackmott42 »

For people curious how much impact the .NET performance improvements over the last 5 years have on real, large scale web applications: At work we have a core piece of our online ordering system that has been running on .NET Framework 4.8. We run around 8 web servers and handle around 4,000 orders per minute, 300 requests per second per server.

We have been working on porting everything over to .NET 6 by making all the code compatible so we can build both from the same code base, and we just started putting the .NET 6 version live on one of the webservers for a few hours at a time to test it out.

CPU usage on that .NET 6 machine is 1/2 of the Framework machines! Impressive improvement, and .NET 7 should be even better.

Re: Performance Improvements in .NET 7

#68

Post by davidfowl »

merb wrote: post #55
davidfowl wrote: post #46

Earlier quoted context omitted.

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…

Actually system text json does work with source generators and di can work with source Generators aswell.

Thanks for telling me :). On a serious note though, anything can work with source generators but it doesn't match the style of coding that we'd like (moving everything to be declarative isn't the path we want to go down for certain APIs). Also source generators don't compose, so any source generation that we would want to use would need to take advantage of the JSON source generator (if we wanted to keep things NativeAOT safe). Right now most of the APIs you use in ASP.NET Core are imperative and source generators cannot change the callsite so you need to resort to method declarations and attributes everywhere.

That's not an optimization, that's a programming model change.

Re: Performance Improvements in .NET 7

#69

Post by nightski »

jabart wrote: post #26
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 bu…

Pretty sure they mean Nullable reference types which are much newer (although they have been around for a while at this point).

Re: Performance Improvements in .NET 7

#70

Post by ahtihn »

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…

Why would you list the .NET version on your CV? Why would anyone hiring care about whether you have experience with .NET 6 vs .NET 3

Do you also list all the library versions you've worked with?

This is pretty absurd.

Post reply on HN