Hacker News Reader

Comment by oconnor663 | Hacker News Reader

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

View on HN

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-lang... https://www.youtube.com/watch?v=mLX1sYVf-Xg

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

The gotcha is method tainting. You have to duplicate every waiting method if you want to support synchronous and asynchronous API. And it spreads.

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.

If there's no actual yield, async/await IS synchronous.

The method still needs to allocate a Task, though. ValueTask along with more aggressive placement of structs in registers helps with that in more recent .NET versions, but it's still not entirely free.

Async / Await can actually happen synchronously if there is no yield.

This is principally a throughput-vs-latency thing, right? Async promises better throughput because concurrency, potentially at the cost of latency.

Async/await can do more than goroutines but because of the explicit nature you do need to be more careful. Not being foolproof is certainly a gotcha.

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 :)

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

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.

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.

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.

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.

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.

StackOverflow was founded in 2008 and probably had plenty of "production load" circa 2010.

StackOverflow is also a classic example of an engineering system that has focused on performance since the very beginning.

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.

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.

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.

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

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.

Probably because C doesn't have a garbage collector or interpreter. And despite all the evidence suggesting that bytecode interpreters on top of JIT compilers with generational GC is plenty fast enough for a huge number of applications, with additional benefits like memory safety and lower development time, devs are still convinced that big == bad and slow.

Maybe. Probably not as bad and slow as you think it is. .NET and Java really don't have the performance overhead that everyone thinks they do, but a corollary of that is C and C++ aren't as fast as you think they are. All that GC tuning you see on JVMs is the same work you do converting to data oriented code in your favorite systems language, you're just fighting the memory wall. While GC's can do it smarter than a human can, they just can't do it for free.

Because people equate startup time with speed? Seriously, Java was never slow compared to the things that I actually saw people comparing it to. I've seen people pick Javascript over Java, because of performance and it just made no sense. Notably that incident was over 10 years ago, when JS was actually pretty slow relative to today.

I can't think of a time when Python, PHP, Perl, or Ruby were faster than Java and yet I saw people acting as if they were.

Your argument is basically myths and misconceptions don't exist, which seems pretty weak.

One reason is that Java GUI applications were noticeable and annoyingly slow to run, compared to native Windows applications.

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

Did anyone ever think it was slower that Python?!

Reply on news.ycombinator.com