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

101–110 of 164 posts

Re: Performance Improvements in .NET 7

#101

Post by guhidalg »

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

It seems you had a bad time learning ASP.NET, but in my experience what you're asking for is not difficult at all.

You have to: 1. [Optional] Define a DTO that deserializes { "foo" : { "bar" : "baz" }} to an object 2. Write a class that subclasses Controller 3. Write a method, call it whatever you want, that accepts a JObject or one of your DTO types. 4. Add the attribute [HttpPut("ping/pong/yolo")] to tell the framework this method should be bound to PUTs for that path. 5. Write your business logic.

Is that blood-crying inducing? No.

Re: Performance Improvements in .NET 7

#102

Post by guhidalg »

mikece wrote: post #47
kryptiskt wrote: post #10

Earlier quoted context omitted.

Every other release is an LTS release, with three years of support. .NET 6 was one so this won't be. They are pretty good about backwards compatibility, upgrading .NET Core and .NET hasn't been a big deal so far.

I have an issue with calling three years "long term" support. Most companies won't update to the new LTS for 9 to 12 months in order for any issues to be ironed out, so that means you get only 24 to 27 months on the LTS. Between CVEs and upgrading to dotnet6 before the end of life on dotnet3.1 most of my coworkers and I have gotten almost no new coding done on our applications this summer (and this was after a three…

What did you have to rewrite when upgrading from .NET 3.1 to 6? If all you had to touch was ASP.NET startup changes, that's hardly 1 day's worth of work.

Re: Performance Improvements in .NET 7

#103

Post by phillipcarter »

romanhn wrote: post #20
fabian2k wrote: post #11

Earlier quoted context omitted.

I think typical ASP.NET applications likely won't use AOT in the near future. There is quite some "magic" in ASP.NET that I suspect won't work out of the box with AOT because it is heavily reflection-based. And while there are solutions for cases like JSON serialization, as far as I understand they require writing different code right now, so it's not automatic. AOT is much, much more interesting for cases where star…

As someone writing a .NET-based API hosted on AWS Lambda, I assure you, startup time matters a ton. I spent a bunch of time getting cold start time down to a semi-reasonable number, but there's still a ton of room for improvement. I for one am very much looking forward to progress on AOT Native.

FWIW the problems with cold starts could also be solved at the platform layer. App startup is what typically dominates cold start times and there's creative ways to potentially frontload that, serialize the state, and treat all invocations as "warm".

Re: Performance Improvements in .NET 7

#104

Post by zeroc8 »

kevingadd wrote: post #77
geodel wrote: post #24

Earlier quoted context omitted.

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…

I do extensive profiling of managed apps and while the JIT does eat a measurable amount of CPU time, it's really not much. And at least on .NET, you can manually ask the runtime to JIT methods, so you can go 'okay, it's startup time, I'm going to spin up a pool of threads and use them to JIT all my code' without blocking execution - for a game I'm working on it takes around 2 seconds to warm ~4000 methods while the o…

I 've never understood the point of JITing. Just compile the thing once for your target architecture and you're done. No more spawning threads for doing the same thing over and over again. I'm glad that languages like Go and Rust are bringing back the lost simplicity of yesteryear's dinosaur languages. Life can be so easy.

Re: Performance Improvements in .NET 7

#105

Post by ewjt »

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.

It’s a minor signal, but it’s still a signal.

If someone only lists “Angular”, it could be Angular 4 from 2016 or something more relevant.

Same thing with .NET— the version can imply Windows-related experience (.NET Framework) vs. something more cloud native (.NET 6).

Re: Performance Improvements in .NET 7

#106

Post by chusk3 »

devmunchies wrote: post #71

> A huge amount of effort in .NET 7 went into making code gen for Arm64 as good or better than its x64 counterpart Awesome. I was using an LSP server for F# (in Sublime Text) on an M2 Mac and it was always running at 500%+ CPU. I had to turn off the LSP server. Hopefully this version fixes it.

Assuming you're talking about FsAutoComplete and this was recently, that's nothing to do with the .NET Runtime and entirely a coding mistake that I made that we've released a fix for :)

Re: Performance Improvements in .NET 7

#107

Post by ewjt »

SideburnsOfDoom wrote: post #37
ewjt wrote: post #35

Earlier quoted context omitted.

Serverless. Running an ASP.NET app in AWS Lambda is just a few lines of code. However, all of a sudden startup time becomes important for both performance and cost. These investments by Microsoft and others[1] allow .NET to remain relevant and viable for modern use cases. [1] https://github.com/awslabs/dotnet-nativeaot-labs

Serverless is great, but if you want to go that route you should be aware that it is in no way a typical hosted ASP.NET app, and while you can "Run an ASP.NET app in AWS Lambda" with little code, there are are better ways to design a Lambda.

Can you elaborate on “is in no way a typical hosted ASP.NET app”?

I get that the machinery under the hood is different (ie. Kestrel web server may not get used). However, we typically don’t care about those details. Our ASP.NET code runs in 3 separate places (containers, servers, Lambda) and the only difference between all 3 is a single entry point file.

Do you mean because Lambda is only serving one request at a time and has a more ephemeral host process lifetime?

Re: Performance Improvements in .NET 7

#108

Post by jayd16 »

AtNightWeCode wrote: post #97
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 sinc…

Newtonsoft isn't AOT friendly though. That's why they went with both.

Re: Performance Improvements in .NET 7

#109

Post by whoisthemachine »

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.

Yes I understand the function coloring "problem" (oh no functions need to specify in their signature whether they return results immediately or eventually). Regardless, I still don't understand how this prevents green threads a la Project Loom, if you have a function that returns a `CompletableFuture` in Java, it also needs to change its signature.

Re: Performance Improvements in .NET 7

#110

Post by ewjt »

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?

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.

Here’s a concrete ASP.NET example: You can put an [ApiController] attribute on your controllers and it can change the structure of error responses, among other things. [1]

I don’t agree with some of the other parent points. For example, the comments on “multiple dependency injection container” —- ASP.NET is pretty prescriptive on DI patterns. That sounds like someone made a decision to add complexity, which is on them.

[1] https://stackoverflow.com/a/66546105

Post reply on HN