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

51–60 of 164 posts

Re: Performance Improvements in .NET 7

#51

Post by bestinterest »

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 very much like the ethos of Golang for this reason. Still not had a reason to use it but like the idea of mastering the fundamentals in a weekend. Even if I lose the flexibility of LINQ or Java streams.

It feels like a scale of language conservativeness Go all the way at the top, Java somewhat in the middle (a little above) and C# at the bottom. It is going the route with lots of features and complexity, which can be a great thing but not for grug devs https://grugbrain.dev like me.

But saying all that Blazor looks really good for WebDev, I just worry it gets abandoned. It feels everything does in the C# space.

C# also made a big mistake imo by going with async/await instead of lightweight threads which will add a ton of complexity in the future for if they decide to go the greenthread route like Goroutines/Project Loom.

Re: Performance Improvements in .NET 7

#52

Post by MarkSweep »

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…

A lot of these things you will get the benefit from upgrading. Also see the last section of the post about analyzers. You can enable these and Visual Studio will identify and potentially automatic improve performance by using different APIs.

There are a performance ton knobs you can turn both at develop time and deployment time. There are 4 ways to run Regexes in .NET 7! (Interpreted, compiled, the new non-backtracking interpreter, the new compile time source generator). I do agree with the assessment that it’s hard to keep up with.

Re: Performance Improvements in .NET 7

#53

Post by asdajksah2123 »

ewjt wrote: post #30
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 sinki…

Front end development may have a lot of frameworks, etc., but so much less magic than .Net.

What makes .Net so much harder (especially ASP.Net) are the new features but also all the magic that makes discoverability so hard.

Front end frameworks tend to follow similar patterns, and where they differ, they usually advertise the difference between the standards heavily.

But also, since they are genuinely different frameworks, it's easier to search the differences etc. So, if I open a Vue application codebase, I know almost immediately that it's a Vue application and not a React one. I can google vue and figure out (most likely from their getting started page) exactly all I need to know to get started.

If I enter an ASP.Net codebase, on the other hand, I have no idea whether I'm looking at ASP.Net Pages, .Net WebAPI, .Net WebServices, or more often than not, some combination of all of them. Throw in some Dependency Injection, with a combination of IOC containers used in the same project, and it's a massive lift to know what even to Google for.

Re: Performance Improvements in .NET 7

#54

Post by vsareto »

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…

Bookmark https://devblogs.microsoft.com/dotnet/ and read occasionally. https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/csh... is good for a quick overview of language features depending on what version you're at.

Most .NET devs only need to be peripherally aware of these changes, as most businesses using .NET will move slower than Core's new pacing. It's even less important for lower seniority devs as you typically need project changes to utilize new features, which is a call a senior would make, which involves approval/testing/deployment, so a slow process which gives you time to read up on the new features as they're needed.

You're better at your "craft" the more tools you know about and how to apply them, but if your day job prevents you from following the new stuff, I wouldn't worry too much about it.

>I feel .NET Core after a good start is falling into the typical Microsoft trap of constantly cranking out new stuff to do the same thing and leaving it to developers to keep up.

Yeah, the pacing has increasing dramatically from .NET Framework days, but that's probably a good thing. I would just stick to learning about what you do in your day job. .NET has a huge ecosystem compared to other languages, so it's going to be very hard to keep up with everything MAUI is doing if you're doing regular ASP.NET core APIs.

Re: Performance Improvements in .NET 7

#55

Post by merb »

davidfowl wrote: post #46
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…

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

Re: Performance Improvements in .NET 7

#56

Post by keltex »

bestinterest wrote: post #51
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 very much like the ethos of Golang for this reason. Still not had a reason to use it but like the idea of mastering the fundamentals in a weekend. Even if I lose the flexibility of LINQ or Java streams. It feels like a scale of language conservativeness Go all the way at the top, Java somewhat in the middle (a little above) and C# at the bottom. It is going the route with lots of features and complexity, which can…

> But saying all that Blazor looks really good for WebDev, I just worry it gets abandoned. It feels everything does in the C# space.

I've been maintaining a asp.net (WebForms!) framework codebase for almost 18 years now. Running on the latest Windows Server and Visual Studio 2022.

Re: Performance Improvements in .NET 7

#57

Post by cyral »

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.

Re: Performance Improvements in .NET 7

#59

Post by uwuemu »

krona wrote: post #13

I wish benchmarks with sample means in the tens of nanoseconds weren't reported and compared by the arithmetic mean. These are not normal distributions and a 10% improvement could just mean you improved the 99% percentile, which is quite typical in my experience given how skewed the distributions tend to be.

... that awkward moment when video game tech reviewers like DigitalFoundry provide better benchmarks of video game performance than a tiny company like Microsoft does for its biggest inhouse programming ecosystem.

Re: Performance Improvements in .NET 7

#60

Post by heurisko »

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…

> And now I see AOT/Slimmed Runtime/Compact packaging are happening largely because of cloud deployments.

I see the main driver of AOT to be startup time for things like lambdas.

The JVM is pretty lightweight anyway on modern hardware, especially if you use modules.

Post reply on HN