Comment by jiggawatts

As far as I know, Dapper performance is within a few percent of "hand rolled" data reader code, because it dynamically compiles the query reader code and then caches the delegate.

Update: a quick test with hand-rolled async query code got me to 41.5K rps, up 3.8% from 40K with Dapper, which doesn't seem worth it. Using non-async produces 43.2K rps for 8% higher perf. That goes to show that using async doesn't necessarily improve performance even under high load!

Entity Framework used to have atrocious performance, but it has been rewritten to work more like Dapper and is quite fast now.

The general issue is that any form of database query in .NET will produce a lot of garbage on the heap. Reading a bunch of "string" values out of a database will... allocate a bunch of strings.

It would be theoretically possible to convert this kind of code to use "ref" types, "span<char>", etc... but then the Razor templating engine wouldn't be able to use this. Similarly, it would be pointless if the output is something like JSON, produced by serializing an object graph. Garbage, garbage, and more garbage for the GC to clean up.

This is why Techempower is so unrealistic. Real developers never write code with "hand rolled delegates", and they shouldn't. They should be writing clear, concise, high-level code using ORMs and template languages like Razor. Not emitting byte arrays to shave nanoseconds off.

Ideally, the languages and frameworks should let the developers to have their cake and eat it too. Rust for example generally allows high level code to be written while minimising the amount of heap usage.