Hacker News Reader

Comment by hu3 | Hacker News Reader

Have you seen the kind of C# code they write to compete in Tech Empower? It's nowhere near what one would write on a daily basis: https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...

Perhaps Go folks should just use inline assembly to demonstrate how useless these benchmarks are.

View on HN

This 1000x times. Should be posted every time someone links to TechEmpower benchmark results. And especially for the most contrived benchmarks like "Plaintext" and "JSON serialization", which are basically echo server competitions that have nothing to do with real applications.

That's nowhere near as bad as inline assembly. It might not be the usual way to write a web app, but it's normal C# with common libraries. Any C# dev could use that as an example if they ran into a major performance issue.

These benchmarks aren't intended to show the performance of everyday code. They show what experts can achieve on each platform. That's why they take pull requests instead of writing the code themselves from tutorials.

That's true. .NET Core high performance optimization looks more approachable.

I'd still rather see the popular way of doing things be the benchmark.

Most code is not CPU-bound, and for code that is, a hot spot is all the usually needs to be optimized. Today .Net Core is remarkably performant, and the fact that just by writing code carefully, or using Span<> etc., you can get close to bare-metal perf with w/o resorting to FFI to unsafe code is a good thing. This is much easier than trying to keep your friendly Rust borrow-checker happy even for moderately complex data-structures with varying lifetimes.

When you put it that way .NET Core runtime does seem to offer great performance at low cost.

btw. these are the platform benchmarks of c# (only kestrel + manually writing the response, basically no framework code) the real ones are in benchmarks (aspcore-mw), which just use a middleware and are also really really fast. btw. golang's std http server is just really really slow. fasthttp solves that and is basically 6x faster in some real code cases.

Reply on news.ycombinator.com