5 ms·

Great, but I would rather see a perf comparison of .NET 5/Core vs .NET 4.7 because .NET Core was a new technology that may have traded performance for features

Great, but I would rather see a perf comparison of .NET 5/Core vs .NET 4.7 because .NET Core was a new technology that may have traded performance for features in its first versions. Similar to how JDK 14 beats JDK9..13 but still in many cases is behind JDK8.

gameswithgo 6y ago
there are no language features traded. some platform specific libraries are not available on core.
- platz 6y ago
  Core doesn't have Distributed Transactions
  - gameswithgo 6y ago
    that falls under the "platform specific library", which I guess I should have clarified, does include things in the standard library.
- smarx007 6y ago
  traded "performance for [added] features" not "features for performance"
GordonS 6y ago
The opposite is true - the .NET5/Core runtimes have optimisations that aren't in .NET Framework CLR. I haven't come across a package that isn't available for .NET Core in at least a couple of years, I think.
resoluteteeth 6y ago
I think that on the contrary, .net core already had much better performance but less support for some desktop windows stuff, and .net 5 actually added most of the remaining features back.
runevault 6y ago
Core 2.2 was significantly faster than Framework 4.7+. Core 3.1 was noticeably faster than that, and how .NET 5 is the fastest yet.
oaiey 6y ago
.NET Framework had a outdated Web stack (System.Web over IIS). In 2014 it was 13 years old with little chance to improve anything without breaking someone. That was the whole reason why .NET Core became a thing. .NET Core in Version 1.0 cheated then by just taking the network layer of node.js called libuv and linked it up (C -> .NET) . In Version 2.x they wrote and independent socket based networking layer straight in C# which outperformed libuv significantly. In Version 3.x they switched over to use new low level runtime primitives (e.g. Span<T>) which could never have been delivered in the .NET Framework (no breaking changes!). Now in .NET 5 more runtime improvements were added.
- deleted 6y ago
  [deleted]
- legulere 6y ago
  Span can be used via nuget also in .NET framework. It’s slower than in Core because of lacking runtime support, but not by that much. SIMD also was already available since 4.6 and unsafe was always there. I think what really changed was the mentality. Before low level stuff was tried to be contained and used mostly for interop. Now the value of the performance of safe low level primitives is seen.
rndgermandude 6y ago
I don't know any definite benchmarks, but anecdote, the unit tests of a bigger library[1] I am writing run in 10s on net5 vs 12s on dotnet 3.1 (core) vs 17s on .net48 (framework), on the same machine with warm caches, of course. That's a sizable difference. YMMV [1] not web stuff, "plain" C# essentially. It has some compute-bound things like encryption and compression and some fancy tree structures, uses a lot of linq in certain parts.

gameswithgo 6y ago

there are no language features traded. some platform specific libraries are not available on core.

platz 6y ago
Core doesn't have Distributed Transactions
- gameswithgo 6y ago
  that falls under the "platform specific library", which I guess I should have clarified, does include things in the standard library.
smarx007 6y ago
traded "performance for [added] features" not "features for performance"

GordonS 6y ago

The opposite is true - the .NET5/Core runtimes have optimisations that aren't in .NET Framework CLR. I haven't come across a package that isn't available for .NET Core in at least a couple of years, I think.

resoluteteeth 6y ago

I think that on the contrary, .net core already had much better performance but less support for some desktop windows stuff, and .net 5 actually added most of the remaining features back.

runevault 6y ago

Core 2.2 was significantly faster than Framework 4.7+. Core 3.1 was noticeably faster than that, and how .NET 5 is the fastest yet.

oaiey 6y ago

.NET Framework had a outdated Web stack (System.Web over IIS). In 2014 it was 13 years old with little chance to improve anything without breaking someone. That was the whole reason why .NET Core became a thing. .NET Core in Version 1.0 cheated then by just taking the network layer of node.js called libuv and linked it up (C -> .NET) . In Version 2.x they wrote and independent socket based networking layer straight in C# which outperformed libuv significantly. In Version 3.x they switched over to use new low level runtime primitives (e.g. Span<T>) which could never have been delivered in the .NET Framework (no breaking changes!). Now in .NET 5 more runtime improvements were added.

deleted 6y ago
[deleted]
legulere 6y ago
Span can be used via nuget also in .NET framework. It’s slower than in Core because of lacking runtime support, but not by that much. SIMD also was already available since 4.6 and unsafe was always there. I think what really changed was the mentality. Before low level stuff was tried to be contained and used mostly for interop. Now the value of the performance of safe low level primitives is seen.

rndgermandude 6y ago

I don't know any definite benchmarks, but anecdote, the unit tests of a bigger library[1] I am writing run in 10s on net5 vs 12s on dotnet 3.1 (core) vs 17s on .net48 (framework), on the same machine with warm caches, of course. That's a sizable difference. YMMV [1] not web stuff, "plain" C# essentially. It has some compute-bound things like encryption and compression and some fancy tree structures, uses a lot of linq in certain parts.