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

131–140 of 164 posts

Re: Performance Improvements in .NET 7

#131

Post by hermitdev »

svick wrote: post #74
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.

Many of the benchmarks are using BenchmarkDotNet, so consider reporting this to them: https://github.com/dotnet/BenchmarkDotNet/ .

Looks like the author is explicitly excluding "Error", "StdDev", "Median", "RatioSD" from the ouput. It's in the setup[0]. I'm guessing the author omitted them for brevity.

[0] https://devblogs.microsoft.com/dotnet/performance_improvemen...

edit: meant "excluding", not "including"

Re: Performance Improvements in .NET 7

#132

Post by metaltyphoon »

ewjt wrote: post #110
metaltyphoon wrote: post #76

Earlier quoted context omitted.

I hear this word all the time “magic”. Can you describe what it means with concrete example for other stacks?

Magic means “hidden complexity”, AKA “abstraction”. The negative connotation is that sometimes you can’t figure out why your software is behaving a certain way and what you need to do about it. The positive connotation is that you write less code with less cognitive overhead. Generally I prefer ASP.NET over things like Spring and Ruby on Rails because it has less magic, despite being clearly inspired by both of those…

So "non magic" means to write everything then? Because the example you showed you have to understand a language feature, attributes. Then see the source code, which is open, and how it's being used.

So, are Rust macros, or C macros, C++ templating magic or it's just means "I don't want to know how this works therefore it's magic"?

Re: Performance Improvements in .NET 7

#133

Post by spaetzleesser »

nightski wrote: post #69
jabart wrote: post #26

Earlier quoted context omitted.

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).

Yes, that's what I meant.

Re: Performance Improvements in .NET 7

#134

Post by bmitc »

pwdisswordfish0 wrote: post #75
jackmott42 wrote: post #67

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

"Framework" is such a poor differentiator to contrast with modern .NET (owing to the original poor naming decision in the first place--it's not like ".NET" itself is amazing) that it's hard, from a casual reading, to pick up on the fact that "Framework" is even being used a differentiator. I propose that when people want to differentiate between the modern .NET Core vs the legacy closed source .NET implementation, th…

I get where people are coming from, but I honestly don't think it's that hard. If someone is new to .NET, all they need to care about is .NET 6 and later, so it doesn't matter much.

Microsoft has documentation for the history. Here's one: https://docs.microsoft.com/en-us/dotnet/core/introduction#ne...

I think everyone is honestly too harsh on Microsoft. They are the best at evolving software (not perfect) while keeping backwards compatibility. Apple and Google just throw things away or suddenly change things and say "deal with it". Of course it's easy to keep naming simple when you do that. There's no way Oracle, Apple, Google, etc. could have managed the transition from .NET Framework to .NET 6 like Microsoft has. Apple would have just changed to something completely different and thus named it something new, just like they did with Swift.

Re: Performance Improvements in .NET 7

#135

Post by bmitc »

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…

And the thing is, Python and Java are much worse than .NET. I use F#, and it is completely seamless to install and use .NET anywhere.

Re: Performance Improvements in .NET 7

#137

Post by neonsunset »

kevingadd wrote: post #84
fabian2k wrote: post #48

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

A polite way to describe most serialization tooling in the .NET ecosystem would be "bad". It's unfortunate, but it's good to see improvements happening. I still try to avoid JSON in general on .NET since I've had so many bad experiences with the various JSON libraries out there. Sadly if you want to ship well-performing software in .NET it's still mandatory to run it under a profiler on a regular basis, both to spot…

Most pitfalls in .NET are luckily along the lines of "punishing people who redo all the steps on each method call or write code Java style" which might even be a good thing. I wonder where does your bad experience with Json libraries come from? Even back in the days of .NET Framework, there was a variety of quality libraries such as Newtonsoft.JSON, Utf8Json or other more interesting but less feature-rich packages.

Nowadays, STJ provides quite good defaults and in places where they differ from Newtonsoft, there usually is a reason for that. I'm not saying all APIs are successful, namely, I consider OOB API for source generated serialization to be really user-unfriendly.

However, other than that, just don't do unnecessary work and cache stateless objects like serializer settings. This translates to most programming languages and isn't something C# specific.

Re: Performance Improvements in .NET 7

#138

Post by neonsunset »

cerved wrote: post #90
metaltyphoon wrote: post #76

Earlier quoted context omitted.

I hear this word all the time “magic”. Can you describe what it means with concrete example for other stacks?

Http request handling in asp.net mvc. The uri, type and parameter serialization is a magic mess. How do you PUT { "foo" : { "bar" : "baz" }} to ping/pong/yolo? You create a controller class, PingController, you create a method PutPong, then you give up and proceed to cry blood

app.MapPut("ping/pong/yolo", ([FromBody] Payload request) => {...});

record Payload(Foo Foo);

record Foo(string Bar);

or

app.MapPut("ping/pong/yolo", (JsonElement json) => {...});

Basically, just avoid outdated blog posts and articles :D

Re: Performance Improvements in .NET 7

#139

Post by davidfowl »

jeremycarter wrote: post #119
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…

Thanks for your hard work with the .NET community David.

Thanks for using .NET!

Re: Performance Improvements in .NET 7

#140

Post by dyml »

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…

It’s incredibly exciting to follow your work and the teams!

Thank you!

Post reply on HN