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

111–120 of 164 posts

Re: Performance Improvements in .NET 7

#111

Post by [deleted] »

pjmlp wrote: post #38
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…

Actually I think it is more competition pressure of languages like Go and Rust than anything else. I have been using Java and .NET languages for distributed computing for the last two decades, and JIT has always been good enough. By the way, Google rolled back their AOT compiler introduced on Android 5, and since Android 7 it uses a mix of highly optimized interpreter written in Assembly, a JIT compiler with PGO feed…

[deleted]

Re: Performance Improvements in .NET 7

#112

Post by whoisthemachine »

blackoil wrote: post #73
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…

IIRC, the statement was from some Java blog about Loom. Idea is that with lightweight threads you can make everything sync and still be performant. While C# has gone ahead with making everything async

I understand the difference in approaches. However, the parent stated that this decision makes green threads harder in C#, which is what I don't understand.

Re: Performance Improvements in .NET 7

#113

Post by AtNightWeCode »

jayd16 wrote: post #108
AtNightWeCode wrote: post #97

Earlier quoted context omitted.

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.

AOT? I really don't understand why they made the transition to System.Text.Json impossible for most projects.

Re: Performance Improvements in .NET 7

#114

Post by esprehn »

gavinray wrote: post #80
esprehn wrote: post #33

Unfortunately looks like still no compact strings like Java or JS: https://github.com/dotnet/runtime/issues/6612 You can work around it, but it's nice in languages where common text doesn't take double the memory (because of utf8 or compact strings).

Is this what you're talking about? > "Arguably the biggest improvement around UTF8 in .NET 7 is the new C# 11 support for UTF8 literals." > "UTF8 literals enables the compiler to perform the UTF8 encoding into bytes at compile-time. Rather than writing a normal string, e.g. "hello", a developer simply appends the new u8 suffix onto the string literal, e.g. "hello"u8. At that point, this is no longer a string. Rather,…

No, not unless you can pass a ReadOnlySpan into every API that expects a String. The change you referenced let's folks work around the fact that String is UTF16. It doesn't transparently handle ASCII with one byte like other languages.

See the GitHub issue or https://openjdk.org/jeps/254

The .NET 7 change doesn't retain backwards compatibility

Re: Performance Improvements in .NET 7

#115

Post by SideburnsOfDoom »

ewjt wrote: post #107
SideburnsOfDoom wrote: post #37

Earlier quoted context omitted.

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

> Lambda is only serving one request at a time and has a more ephemeral host process lifetime

Yes, a typical hosted ASP.NET app is neither ephemeral or one request at a time. So this drives different design decisions.

Re: Performance Improvements in .NET 7

#116

Post by whoisthemachine »

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…

A suggestion I liked was to call ".Net Framework" ".Net classic" a la "ASP classic", nicely honors the original .Net while properly suggesting it is not the "new" .Net.

Re: Performance Improvements in .NET 7

#117

Post by whoisthemachine »

na85 wrote: post #87
pwdisswordfish0 wrote: post #75

Earlier quoted context omitted.

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

It feels like it must be a company policy. When needing to compete with other major tools, choose a name so generic and so easily confused with other things that people who have no knowledge of the product will assume they need it. I can imagine some IT conversations 20 years ago along the lines of ".Net? I must need that for internet access!", just like I'm sure there are discussions today where managers assume they need Azure DevOps to get this new-fangled DevOps thing.

Re: Performance Improvements in .NET 7

#118

Post by pwdisswordfish0 »

wombarly wrote: post #83
pwdisswordfish0 wrote: post #75

Earlier quoted context omitted.

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

Not a name change, just an editorial prescription for discussions. The proper name is .NET Framework (just don't call it that!).

Re: Performance Improvements in .NET 7

#119

Post by jeremycarter »

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…

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

Re: Performance Improvements in .NET 7

#120

Post by lillecarl »

zeroc8 wrote: post #104
kevingadd wrote: post #77

Earlier quoted context omitted.

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.

Reflection in C# is a thing, it isn't in either Go or Rust. I've read some kind of compiler shenanigans can get something that resembles reflection in C++.

I love reflection, the fact that libraries can look at your types is really really cool.

Not saying it can't be done with a compiled language but I don't see it anywhere.

Being able to load a shared library, search it for classes implementing interfaces, instantiate them and call their methods is pretty slick too.

Post reply on HN