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

91–100 of 164 posts

Re: Performance Improvements in .NET 7

#91

Post by metaltyphoon »

bestinterest wrote: post #82
whoisthemachine wrote: post #72

Earlier quoted context omitted.

> 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. Could you expand on this? Async/await is just syntax magic for Task continuations (in other words, Promises [0]), which have very little to do with the underlying threading model. This statement is equiva…

I think this post has the best information on it as I am also learning here https://journal.stuffwithstuff.com/2015/02/01/what-color-is-... It is not just `magic` syntax imo, it is viral to your codebase. The blog post does way more justice than I can explain.

For what it's worth, there is experimentation of green thread in C# happening.

Re: Performance Improvements in .NET 7

#92

Post by nightski »

danparsonson wrote: post #81
ahtihn wrote: post #70

Earlier quoted context omitted.

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.

The .NET framework has changed a great deal between versions 1 and 6, so I don't agree that it's sufficient just to say that I am experienced with .NET and leave it at that, nor is it equivalent to listing library versions. Besides I'm a contractor; potential customers are usually looking for someone who can hit the ground running, not spend a month skilling up.

If a recruiter denies you because you have .NET 6 on your resume instead of .NET 7 then that probably isn't a very lucrative job in the first place. You don't need a month of skill up to go from 6 to 7, maybe like 10 minutes.

Personally I'd just say .NET in general and leave the specifics to the interview.

Re: Performance Improvements in .NET 7

#93

Post by branko_d »

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…

IMHO, they should have just named the new one .CORE and called it a day.

It would have made it immeasurably easier to google, and could have been be incorporated into other names to differentiate them from old versions: ASP.CORE, ADO.CORE, WinForms.CORE…

Re: Performance Improvements in .NET 7

#95

Post by aliswe »

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…

Streaming serialization with System.Text.Json doe.

Re: Performance Improvements in .NET 7

#96

Post by phillipcarter »

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've taken to calling it "Legacy .NET".

Re: Performance Improvements in .NET 7

#97

Post by AtNightWeCode »

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…

Yeah, it should be in a static property/field or a singleton. Seen measurable improvements based on fixing this. System.Text.Json really has many unnecessary pitfalls. Maybe they should have fixed the memory problems with Newtonsoft instead. A much more practical lib.

Edit: With that said, in most apps JSON speed is very not important. Never seen it consumed more than couple of percent of execution time for APIs since .NET 1.1.

Re: Performance Improvements in .NET 7

#98

Post by aliswe »

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

something like

app.MapPut("ping/pong/yolo", ctx => ...);

and in there you read the Body as string ... it should be a one liner?

Re: Performance Improvements in .NET 7

#100

Post by mastax »

There was a (very long) post recently talking about the Regex performance improvements in .NET 7[0]. It's comprehensive and well written and I found it very interesting. I love the new Regex source generator not just because of the performance but because you can step into the C# code and understand pretty well what the regex is doing.

[0]: https://devblogs.microsoft.com/dotnet/regular-expression-imp...

Post reply on HN