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

81–90 of 164 posts

Re: Performance Improvements in .NET 7

#81

Post by danparsonson »

ahtihn wrote: post #70
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…

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.

Re: Performance Improvements in .NET 7

#82

Post by bestinterest »

whoisthemachine wrote: post #72
bestinterest wrote: post #51

Earlier quoted context omitted.

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…

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

Re: Performance Improvements in .NET 7

#83

Post by wombarly »

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…

Please, no more name changes.

Re: Performance Improvements in .NET 7

#84

Post by kevingadd »

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 frequent unnecessary GC allocations and to spot CPU bottlenecks. Either one would probably catch this particular problem, thankfully!

I use the built in VS profilers sometimes, and other times I use Superluminal's excellent CPU profiling.

Re: Performance Improvements in .NET 7

#85

Post by kevingadd »

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…

You really don't need to use any new features to get the benefit of improvements in many cases, because the standard library is updated to use them. So things like string and array operations just get faster.

I've started using 'ref readonly' and stuff like that in bits and pieces of my application code, but the rest of it is basically written in a .NET 4.0 style and it's fine, there's no obligation to use the new stuff unless you want to. I've started using some of the newer syntax sugar to make things more concise, like local functions, value tuples, and short property definitions - but again that's totally optional.

Re: Performance Improvements in .NET 7

#86

Post by kevingadd »

uwuemu wrote: post #59
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.

Video game performance is generally measured in milliseconds, not nanoseconds. The comparison would be if you were benchmarking things like physics sim updates on a per-object basis, or rendering on a per-triangle basis. Those would also be in nanoseconds.

As a game dev you're typically operating in terms of things like 'rendering our UI is taking 0.5ms, can we get it lower so we have more time for the terrain?'

Re: Performance Improvements in .NET 7

#87

Post by na85 »

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…

Microsoft is so incredibly bad at naming things it'd be hilarious if it wasn't so frustrating.

Re: Performance Improvements in .NET 7

#88

Post by ewjt »

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…

The annual cadence simplifies our planning— we can preview features a year ahead and prepare for the LTS release. It also shortens the feedback cycle for Microsoft which has to be useful.

From a recruiting standpoint, it allows me to start conversations. I don’t take points off if candidates haven’t worked on the latest version, but one of my go-to questions is “What features in .NET X are you looking forward to using?”.

In an industry of constant change, it’s a negative signal if you don’t know anything about the current version of the platforms you use. Many, many candidates don’t.

Re: Performance Improvements in .NET 7

#89

Post by jcpst »

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…

Yes, it is terrible. I think you need to be an active .NET developer to communicate those subtle differences clearly.

But we’re used to it being bad at this point. .NET Framework, Microsoft Teams, Visual Studio Code…

Re: Performance Improvements in .NET 7

#90

Post by cerved »

metaltyphoon wrote: post #76
asdajksah2123 wrote: post #53

Earlier quoted context omitted.

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

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

Post reply on HN