5 ms·

> Myth 2: It’s Slower than Node/Python/Go/Rust I guess apples-to-apples benchmarks are so hard to agree on that any statement of the form "A is slower than B"

> Myth 2: It’s Slower than Node/Python/Go/Rust I guess apples-to-apples benchmarks are so hard to agree on that any statement of the form "A is slower than B" is always to some degree a myth. If that's the author's position, fair enough. But if we actually want to make comparisons, "C# is faster than Rust" is a bold claim.

Yoric 5y ago
...especially when in two out of the author's three screen captures, C# is actually shown as slower than Rust. I didn't spent time to investigate further because I feel that this headline is not really useful in the first place.
phillipcarter 5y ago
The reason why it's a myth worth dispelling now is that The (legacy) .NET Framework, which used to be ".NET" back in the day, actually was hilariously slow for any kind of web or networking work. It had decent CPU crunching power, but also only on Windows machines. Comparisons of benchmarks with C# vs. Rust or whatever are unproductive and it's a shame that the article focuses on that. The reality is that you can write C# or F# code today, focus on solving your problem instead of performance, and have it handle a production workload admirably well. That used to not be true circa ~2010. Thankfully it is true now :)
- bastardoperator 5y ago
  This is my experience with dotnet. Considerable amount of legacy code coupled with different web frameworks along the way. While the app was slow, I found the amount of time it took to make changes to be the unbearable part, mostly a whack a mole situation. Maybe I worked with some bad developers, but they all acted as if dotnet was the best thing ever with constant mentions of dependency injection and blaming the GAC for problems they clearly created..
  - nightski 5y ago
    All ecosystems have churn. While .NET has had a fair share of churn, to me it seems in line with any other platform that has not only survived but thrived for this long.
  - gregmac 5y ago
    Most of the problems I've seen of this sort are from easy-to-make design issues, like constantly reassigning a string value to modify it (lots of allocations, with lots of GC), or using an IEnumerable with .count() then iterating with foreach (causes multiple enumerations and maybe loads), or unnecessary conversions between List and arrays. If you don't understand what's happening underneath, these mistakes are easy to make. The worst part is these compound over time, and also aren't obvious at small scale. This isn't a problem unique to .net though.
- hughrr 5y ago
  I disagree. It was pretty good even back in 2005. There were a couple of very large high traffic sites I ran on it back then. I wouldn’t use it now because the big cost is always humans in a project and anything .Net turns into a damage amplifier because of the amount of fettling and dealing with churn you have to do to get anything done. Even with .net 6.
  - tomnipotent 5y ago
    Agreed. I had a web app in 2006 handling 20k RPS on three dual core/2GB servers without breaking a sweat. This included per-server connection pooling to MSSQL and lots of UDP traffic on top of memcached. It was rock solid.
- TideAd 5y ago
  The .NET Framework HttpClient was considered really slow by the .NET team themselves. In .NET Core they scrapped the old code entirely so they could build a good one.
- branko_d 5y ago
  StackOverflow was founded in 2008 and probably had plenty of "production load" circa 2010.
  - phillipcarter 5y ago
    StackOverflow is also a classic example of an engineering system that has focused on performance since the very beginning.
- mark-r 5y ago
  I believe StackOverflow has been running with .NET since they started in 2008, and they were pretty surprised by the scalability and performance. They do use Windows servers though. They've been reasonably open about sharing their architecture.
userbinator 5y ago
That reminds me of all the "Java is not slow" articles that came out back when Java was more popular. If it really wasn't slow, why would they have to defend it? We don't see "C is not slow" articles.
- II2II 5y ago
  I don't know whether modern Java is slow or fast compared to other languages since it tends to be fast enough for many applications these days. Yet Java earned a reputation for being slow in the early days, may that be due to the startup time of the JVM when Java applets were embedded into web pages or the lacklustre performance of overly ambitious applications built upon a (then) immature platform. Even though those issues were dealt with in one form or another (e.g. applets dying off as well as the development and improvement of the JIT compiler), the reputation has been hard to shake. I suspect that much of that is due to a "fool me once, shame on me; fool me twice, shame on you" type of attitude. In other words, people haven't bothered to see if it has improved since early Java did not live up to the early hype.
- colejohnson66 5y ago
  > If it really wasn't slow, why would they have to defend it? We don't see "C is not slow" articles. Because there’s a justifiable concern from some about a bytecode system being slower than raw machine code. After all, bytecode requires, at a minimum, interpretation to run. And with JIT systems, there’s still a cost associated with it. You don’t see “C is not slow” because no one is arguing that it is.[a] There’s nothing faster than machine code[b]. [a]: Maybe back in the day when assembly was still king? If the internet was as prevalent 20 years ago as it is now, I’m sure you’d’ve seen articles arguing “C is not slow” compared to assembly. [b]: Ignoring optimizations. Machine code is as close to the processor you can get.
  - OldTimeCoffee 5y ago
    You would see USENET posts back in the 90s about C/C++ vs ASM basically arguing that C/C++ was better than ASM because hand tuning ASM wasn't worth the man-months of effort required to extract the small amount of additional performance. It's basically the same argument, writing in a higher level language provides more benefit than the performance losses that aren't really that big to begin with.
sremani 5y ago
C# is not faster than Rust - but you can get near Rust performance with all the safety and memory management goodness. On benchmark C# is giving go run for its money! But again, it is easy to get carried away by benchmarks. Go-routines are a killer feature, .Net async/await come with gotchas. The weird space of .Net/.net is because the first 15 or so years - it was hostage to Windows. There by tainting its mind-share and engineering culture. Links (a bit old ones about C# low level chops) https://mattwarren.org/2019/03/01/Is-CSharp-a-low-level-language/ https://mattwarren.org/2019/03/01/Is-CSharp-a-low-level-lang... https://www.youtube.com/watch?v=mLX1sYVf-Xg https://www.youtube.com/watch?v=mLX1sYVf-Xg
- briHass 5y ago
  > .Net async/await come with gotchas. What are the gotchas? The only snags I see with async/await are when developers don't know what they're doing and try to force async methods to be synchronous with .Result. If you async it all the way down the stack: your web controller methods are async / your program's main is async, you'll have no issues. It's actually great, because you don't even have to know the internals or what it's doing.
  - lostmsu 5y ago
    The gotcha is method tainting. You have to duplicate every waiting method if you want to support synchronous and asynchronous API. And it spreads.
  - gregmac 5y ago
    There's a performance penalty which happens if you don't need async (eg, if the innermost thing is actually using Task.FromResult), and I've never tested but there's probably some cutoff point where if an awaited operation is faster than x, it's faster to write non-async code (though x may vary by cpu or some other factors). Practicality speaking, this isn't much of a concern for most code, though. I've only really run into this in a couple specific scenarios: unit tests, and when using something like a message bus or cache layer that has a local/in-memory implementation. I noticed only incidentally (as opposed to because of a perf problem): on unit tests where the time got slightly longer when we changed to async, and in the message bus case when doing some performance profiling and using the "local" dev version.
dehrmann 5y ago
Did anyone ever think it was slower that Python?!

Yoric 5y ago

...especially when in two out of the author's three screen captures, C# is actually shown as slower than Rust. I didn't spent time to investigate further because I feel that this headline is not really useful in the first place.

phillipcarter 5y ago

The reason why it's a myth worth dispelling now is that The (legacy) .NET Framework, which used to be ".NET" back in the day, actually was hilariously slow for any kind of web or networking work. It had decent CPU crunching power, but also only on Windows machines. Comparisons of benchmarks with C# vs. Rust or whatever are unproductive and it's a shame that the article focuses on that. The reality is that you can write C# or F# code today, focus on solving your problem instead of performance, and have it handle a production workload admirably well. That used to not be true circa ~2010. Thankfully it is true now :)

bastardoperator 5y ago
This is my experience with dotnet. Considerable amount of legacy code coupled with different web frameworks along the way. While the app was slow, I found the amount of time it took to make changes to be the unbearable part, mostly a whack a mole situation. Maybe I worked with some bad developers, but they all acted as if dotnet was the best thing ever with constant mentions of dependency injection and blaming the GAC for problems they clearly created..
- nightski 5y ago
  All ecosystems have churn. While .NET has had a fair share of churn, to me it seems in line with any other platform that has not only survived but thrived for this long.
- gregmac 5y ago
  Most of the problems I've seen of this sort are from easy-to-make design issues, like constantly reassigning a string value to modify it (lots of allocations, with lots of GC), or using an IEnumerable with .count() then iterating with foreach (causes multiple enumerations and maybe loads), or unnecessary conversions between List and arrays. If you don't understand what's happening underneath, these mistakes are easy to make. The worst part is these compound over time, and also aren't obvious at small scale. This isn't a problem unique to .net though.
hughrr 5y ago
I disagree. It was pretty good even back in 2005. There were a couple of very large high traffic sites I ran on it back then. I wouldn’t use it now because the big cost is always humans in a project and anything .Net turns into a damage amplifier because of the amount of fettling and dealing with churn you have to do to get anything done. Even with .net 6.
- tomnipotent 5y ago
  Agreed. I had a web app in 2006 handling 20k RPS on three dual core/2GB servers without breaking a sweat. This included per-server connection pooling to MSSQL and lots of UDP traffic on top of memcached. It was rock solid.
TideAd 5y ago
The .NET Framework HttpClient was considered really slow by the .NET team themselves. In .NET Core they scrapped the old code entirely so they could build a good one.
branko_d 5y ago
StackOverflow was founded in 2008 and probably had plenty of "production load" circa 2010.
- phillipcarter 5y ago
  StackOverflow is also a classic example of an engineering system that has focused on performance since the very beginning.
mark-r 5y ago
I believe StackOverflow has been running with .NET since they started in 2008, and they were pretty surprised by the scalability and performance. They do use Windows servers though. They've been reasonably open about sharing their architecture.

userbinator 5y ago

That reminds me of all the "Java is not slow" articles that came out back when Java was more popular. If it really wasn't slow, why would they have to defend it? We don't see "C is not slow" articles.

II2II 5y ago
I don't know whether modern Java is slow or fast compared to other languages since it tends to be fast enough for many applications these days. Yet Java earned a reputation for being slow in the early days, may that be due to the startup time of the JVM when Java applets were embedded into web pages or the lacklustre performance of overly ambitious applications built upon a (then) immature platform. Even though those issues were dealt with in one form or another (e.g. applets dying off as well as the development and improvement of the JIT compiler), the reputation has been hard to shake. I suspect that much of that is due to a "fool me once, shame on me; fool me twice, shame on you" type of attitude. In other words, people haven't bothered to see if it has improved since early Java did not live up to the early hype.
colejohnson66 5y ago
> If it really wasn't slow, why would they have to defend it? We don't see "C is not slow" articles. Because there’s a justifiable concern from some about a bytecode system being slower than raw machine code. After all, bytecode requires, at a minimum, interpretation to run. And with JIT systems, there’s still a cost associated with it. You don’t see “C is not slow” because no one is arguing that it is.[a] There’s nothing faster than machine code[b]. [a]: Maybe back in the day when assembly was still king? If the internet was as prevalent 20 years ago as it is now, I’m sure you’d’ve seen articles arguing “C is not slow” compared to assembly. [b]: Ignoring optimizations. Machine code is as close to the processor you can get.
- OldTimeCoffee 5y ago
  You would see USENET posts back in the 90s about C/C++ vs ASM basically arguing that C/C++ was better than ASM because hand tuning ASM wasn't worth the man-months of effort required to extract the small amount of additional performance. It's basically the same argument, writing in a higher level language provides more benefit than the performance losses that aren't really that big to begin with.

sremani 5y ago

C# is not faster than Rust - but you can get near Rust performance with all the safety and memory management goodness. On benchmark C# is giving go run for its money! But again, it is easy to get carried away by benchmarks. Go-routines are a killer feature, .Net async/await come with gotchas. The weird space of .Net/.net is because the first 15 or so years - it was hostage to Windows. There by tainting its mind-share and engineering culture. Links (a bit old ones about C# low level chops) https://mattwarren.org/2019/03/01/Is-CSharp-a-low-level-language/ https://mattwarren.org/2019/03/01/Is-CSharp-a-low-level-lang... https://www.youtube.com/watch?v=mLX1sYVf-Xg https://www.youtube.com/watch?v=mLX1sYVf-Xg

briHass 5y ago
> .Net async/await come with gotchas. What are the gotchas? The only snags I see with async/await are when developers don't know what they're doing and try to force async methods to be synchronous with .Result. If you async it all the way down the stack: your web controller methods are async / your program's main is async, you'll have no issues. It's actually great, because you don't even have to know the internals or what it's doing.
- lostmsu 5y ago
  The gotcha is method tainting. You have to duplicate every waiting method if you want to support synchronous and asynchronous API. And it spreads.
- gregmac 5y ago
  There's a performance penalty which happens if you don't need async (eg, if the innermost thing is actually using Task.FromResult), and I've never tested but there's probably some cutoff point where if an awaited operation is faster than x, it's faster to write non-async code (though x may vary by cpu or some other factors). Practicality speaking, this isn't much of a concern for most code, though. I've only really run into this in a couple specific scenarios: unit tests, and when using something like a message bus or cache layer that has a local/in-memory implementation. I noticed only incidentally (as opposed to because of a perf problem): on unit tests where the time got slightly longer when we changed to async, and in the message bus case when doing some performance profiling and using the "local" dev version.

dehrmann 5y ago

Did anyone ever think it was slower that Python?!