4 ms·

It’s astounding just how fast modern .NET has become. I’d be curious as to how the .NET (Framework excluded) benchmarks run in a Linux container.

by junto 2y ago

api 2y ago
I wonder how it compares to (1) Go, (2) the JVM, and (3) native stuff like Rust and C++. Obviously as with all such benchmarks the skill of the programmer doing the implementing matters a lot. You can write inefficient clunky code in any language.
- kfuse 2y ago
  All modern popular languages are fast, except the most popular one.
  - paulddraper 2y ago
    And Python+Ruby
  - api 2y ago
    JavaScript is hella fast for a dynamically typed language, but that's because we've put insane amounts of effort into making fast JITing VMs for it.
    - zamalek 2y ago
      Sure, but "for a dynamically typed language" still means that it's slow amongst all languages.
- jeffbee 2y ago
  Java and .NET (and JS or anything that runs under v8 or HotSpot) usually compare favorably to others because they come out of the box with PGO. The outcomes for peak-optimized C++ are very good, but few organizations are capable of actually getting from their C++ build what every .NET user gets for free.
  - metaltyphoon 2y ago
    .NET go as far as having D(ynamic)PGO, which is enabled by default.
- junto 2y ago
  https://medium.com/deno-the-complete-reference/net-vs-java-vs-go-vs-rust-hello-uuid-performance-7ead3e7e79aa https://medium.com/deno-the-complete-reference/net-vs-java-v...
- kristianp 2y ago
  I would say go is not in the same category of speed as rust anf c/c++. The level of optimisation done by them is next level. Go also doesn't inline your assembly functions, has less vectorisation in the standard libraries, and doesn't allow you to easily add vectorisation with intrinsics.
Analemma_ 2y ago
I agree, .NET Core has improved by gigantic leaps and bounds. Which makes it all the more frustrating to me that .NET and Java both had "lost decades" of little to no improvement. Java mostly only on the language side, where 3rd-party JVMs still saw decent changes, but .NET both on the language and runtime side. I think this freeze made (and continues to make) people think the ceiling of both performance and developer ergonomics of these languages is much lower than it actually is.
- paavohtl 2y ago
  I certainly agree that Java / JVM had a lost decade (or even more), but not really with C# / .NET. When do you consider that lost decade to have been? C# has had a major release with new language features every 1-3 years, consistently for the past 20+ years.
  - CharlieDigital 2y ago
    Lost decade in another sense in the case of C#. It's sooooo good now. Fast, great DX, LINQ, Entity Framework, and more! But I still come across a lot of folks that think it's still in the .NET Framework days and bound to Windows or requires paid tooling like Visual Studio.
    - MortyWaves 2y ago
      Those people are all wilfully ignorant at this point.
      - CharlieDigital 2y ago
        I know! I'm working on a large TypeScript codebase right now (Nest.js + Prisma) and it's actually really, really bad. Primarily because Prisma generates a ton of intermediate models as output from the schema. On the other hand, in EF you simply work with the domain model and anonymous types that you transform at the boundary. Nest.js + Prisma ends up being far more complex than .NET web APIs + EF because of this lack or runtime types. Everything feels like a slog.
jiggawatts 2y ago
I just did some benchmarks of this! Linux in general provides the same speed for pure CPU workloads like generating JSON or HTML responses. Some I/O operations run about 20% better, especially for small files. One killer for us was that the Microsoft.Data.SqlClient is 7x slower on Linux and 10x slower on Linux with Docker compared to a plain Windows VM! That has a net 2x slowdown effect for our applications which completely wipes out the licensing cost benefit when hosted in Azure. Other database clients have different performance characteristics. Many users have reported that PostgreSQL is consistent across Windows and Linux.
- neonsunset 2y ago
  > Microsoft.Data.SqlClient is 7x slower on Linux It is probably worth reporting your findings and environment here: https://github.com/dotnet/SqlClient https://github.com/dotnet/SqlClient Although I'm not sure how well-maintained SqlClient w.r.t. such regressions as I don't use it. Also make sure to use the latest version of .NET and note that if you give a container anemic 256MB and 1C - under high throughput it won't be able to perform as fast as the application that has an entire host to itself.
  - jiggawatts 2y ago
    I’m using the latest everything and it’s still slow as molasses. This issue has been reported years ago by multiple people and Microsoft has failed to fix it, despite at least two attempts at it. Basically, only the original C++ clients work with decent efficiency, and the Windows client is just a wrapper around this. The portable “managed”, MARS, and async clients are all buggy (including data corruption) and slow as molasses. This isn’t because of the .NET CLR but because of O(n^2) algorithms in basic packet reassembly steps! I’ve researched this quite a bit, and a fundamental issue I noticed was that the SQL Client dev team doesn’t test their code for performance with realistic network captures. They replay traces from disk, which is “cheating” because they never see a partial buffer like you would see on an Ethernet network where you get ~1500 bytes per packet instead of 64KB aligned(!) reads from a file.
    - 2y ago

It’s astounding just how fast modern .NET has become. I’d be curious as to how the .NET (Framework excluded) benchmarks run in a Linux container.

by junto 2y ago

It’s astounding just how fast modern .NET has become. I’d be curious as to how the .NET (Framework excluded) benchmarks run in a Linux container.

api 2y ago

I wonder how it compares to (1) Go, (2) the JVM, and (3) native stuff like Rust and C++. Obviously as with all such benchmarks the skill of the programmer doing the implementing matters a lot. You can write inefficient clunky code in any language.

kfuse 2y ago
All modern popular languages are fast, except the most popular one.
- paulddraper 2y ago
  And Python+Ruby
- api 2y ago
  JavaScript is hella fast for a dynamically typed language, but that's because we've put insane amounts of effort into making fast JITing VMs for it.
  - zamalek 2y ago
    Sure, but "for a dynamically typed language" still means that it's slow amongst all languages.
jeffbee 2y ago
Java and .NET (and JS or anything that runs under v8 or HotSpot) usually compare favorably to others because they come out of the box with PGO. The outcomes for peak-optimized C++ are very good, but few organizations are capable of actually getting from their C++ build what every .NET user gets for free.
- metaltyphoon 2y ago
  .NET go as far as having D(ynamic)PGO, which is enabled by default.
junto 2y ago
https://medium.com/deno-the-complete-reference/net-vs-java-vs-go-vs-rust-hello-uuid-performance-7ead3e7e79aa https://medium.com/deno-the-complete-reference/net-vs-java-v...
kristianp 2y ago
I would say go is not in the same category of speed as rust anf c/c++. The level of optimisation done by them is next level. Go also doesn't inline your assembly functions, has less vectorisation in the standard libraries, and doesn't allow you to easily add vectorisation with intrinsics.

Analemma_ 2y ago

I agree, .NET Core has improved by gigantic leaps and bounds. Which makes it all the more frustrating to me that .NET and Java both had "lost decades" of little to no improvement. Java mostly only on the language side, where 3rd-party JVMs still saw decent changes, but .NET both on the language and runtime side. I think this freeze made (and continues to make) people think the ceiling of both performance and developer ergonomics of these languages is much lower than it actually is.

paavohtl 2y ago
I certainly agree that Java / JVM had a lost decade (or even more), but not really with C# / .NET. When do you consider that lost decade to have been? C# has had a major release with new language features every 1-3 years, consistently for the past 20+ years.
- CharlieDigital 2y ago
  Lost decade in another sense in the case of C#. It's sooooo good now. Fast, great DX, LINQ, Entity Framework, and more! But I still come across a lot of folks that think it's still in the .NET Framework days and bound to Windows or requires paid tooling like Visual Studio.
  - MortyWaves 2y ago
    Those people are all wilfully ignorant at this point.
    - CharlieDigital 2y ago
      I know! I'm working on a large TypeScript codebase right now (Nest.js + Prisma) and it's actually really, really bad. Primarily because Prisma generates a ton of intermediate models as output from the schema. On the other hand, in EF you simply work with the domain model and anonymous types that you transform at the boundary. Nest.js + Prisma ends up being far more complex than .NET web APIs + EF because of this lack or runtime types. Everything feels like a slog.

jiggawatts 2y ago

I just did some benchmarks of this! Linux in general provides the same speed for pure CPU workloads like generating JSON or HTML responses. Some I/O operations run about 20% better, especially for small files. One killer for us was that the Microsoft.Data.SqlClient is 7x slower on Linux and 10x slower on Linux with Docker compared to a plain Windows VM! That has a net 2x slowdown effect for our applications which completely wipes out the licensing cost benefit when hosted in Azure. Other database clients have different performance characteristics. Many users have reported that PostgreSQL is consistent across Windows and Linux.

neonsunset 2y ago
> Microsoft.Data.SqlClient is 7x slower on Linux It is probably worth reporting your findings and environment here: https://github.com/dotnet/SqlClient https://github.com/dotnet/SqlClient Although I'm not sure how well-maintained SqlClient w.r.t. such regressions as I don't use it. Also make sure to use the latest version of .NET and note that if you give a container anemic 256MB and 1C - under high throughput it won't be able to perform as fast as the application that has an entire host to itself.
- jiggawatts 2y ago
  I’m using the latest everything and it’s still slow as molasses. This issue has been reported years ago by multiple people and Microsoft has failed to fix it, despite at least two attempts at it. Basically, only the original C++ clients work with decent efficiency, and the Windows client is just a wrapper around this. The portable “managed”, MARS, and async clients are all buggy (including data corruption) and slow as molasses. This isn’t because of the .NET CLR but because of O(n^2) algorithms in basic packet reassembly steps! I’ve researched this quite a bit, and a fundamental issue I noticed was that the SQL Client dev team doesn’t test their code for performance with realistic network captures. They replay traces from disk, which is “cheating” because they never see a partial buffer like you would see on an Ethernet network where you get ~1500 bytes per packet instead of 64KB aligned(!) reads from a file.
  - 2y ago