[hmexx]

List of performance improvements is mind-boggling:

https://devblogs.microsoft.com/dotnet/performance-improvemen...

How could a mature standard library / frameworks have so much performance gains to be had?

[benaadams]

And in 2.0 https://devblogs.microsoft.com/dotnet/performance-improvemen...

And in 2.1 https://devblogs.microsoft.com/dotnet/performance-improvemen...

3.0 has new JIT capabilities like CPU hardware intrinsics; devirtualization; Span etc which in turn enable new techniques in the standard library.

Though 3.0 is a vast set of improvements compared to the previous two

[fortran77]

The "core" library was designed for portability and it's not as old as the .NET used for Windows desktop development, which is very mature and very performant.

[benaadams]

.NET Core is faster than .NET Framework

[nathanaldensr]

One can hardly call .NET Core "a library." It's an API surface area (.NET Standard), a cross-platform implementation of said surface area (.NET Core), a cross-platform runtime (CoreCLR), and a CLI tool (dotnet). It's already introduced numerous performance enhancements over .NET Framework (e.g., Span<T>, Memory<T>, and the runtime itself).

IMO, .NET Framework should be relegated to the dustbin of history. There is no longer a reason to use it unless you are writing legacy code (which, granted, is a legitimate reason in many cases). For greenfield projects, I hope you're using .NET Standard and .NET Core.

[giulianob]

I believe most of these are from Span which allows doing a lot of operations (e.g. substring) without allocating a new object.

[oaiey]

Well, in the traditional desktop space performance was not that critical as it is with cloud deployments. Also hardware intrinsics are a new toy they have available.

[Gibbon1]

Seems to me it was fast enough on the desktop and uniformly responsive to events. If you wanted a Windows CRUD desktop application, really nothing better.

I suspect that the CLI and the JVM are about as fast, about 2 to 10 times slower than C++. But that .nets libraries are more performant.

[9wzYQbTYsAIc]

A lot of work was done recently with compiler optimizations and using hardware intrinsics for core functions.

[The_rationalist]

Would be really nice to see performance comparisons against a chromium equivalent for the same UX.

[thrower123]

Memory usage difference should be something like an order of magnitude better with .NET.

It's not a direct comparison, because the features aren't quite the same, but the Electron Teams app uses about 10x more memory than the relatively heavy WPF Skype for Business client that it's supposed to replace.

[michannne]

Chromium is naturally bloated and heavy, what would be the goal in comparing it to WPF

[Analemma_]

I think it's a combination of monopoly effects plus the benefits of open source: back when .NET was closed-source and only available on Windows, the only way to ship a performance improvement was if an individual developer at Microsoft could convince his boss it was worth it. And it was rarely worth it, because .NET only ran on Windows, its only customers were .NET-only enterprise shops who weren't about to move to an entirely new framework because of perf problems, and there was always a long list of feature requests that PMs would give priority to.

But now that .NET runs everywhere, it has to compete with projects that have been shipping performance improvements all along. Happily, since it's now open-source too, it can accept those changes from anyone.

[sebazzz]

It is more about backwards compatibility than anything else. Remember that .NET Framework is something that ships with an operating system (Windows) and has components built on this shared runtime: not only devtools like SSMS and Visual Studio but core Windows components like MMC applets and things like ADFS / Remote Desktop Gateway as well. This puts up a bar regarding backwards compatibility. Not only code that is written against the runtime need to be compatible, but also code hosting the runtime, debugging the runtime, the profiler API, and I could go on.

This yields some constraints in whatever is possible changing. Want to add new IL instructions? No can do. Need to change the debugger API? No can do.

Please also see this: https://news.ycombinator.com/item?id=18364032

[fortran77]

The "proprietary" .NET was very performant. It's the new "open" one that has to catch up.