Tortuga Chain VS RawDataAccessBencher

I mean, look at this mess: https://github.com/TortugaResearch/Tortuga.Chain/blob/main/Tortuga.Chain/Tortuga.Chain.SqlServer/shared/SqlServer/SqlServerMetadataCache.cs

Omg I didn’t realize this was you: https://github.com/TortugaResearch/Chain

You can see a comparison in the ORM Cookbook. https://tortugaresearch.github.io/DotNet-ORM-Cookbook/ and this (out of date) post https://github.com/TortugaResearch/Chain/wiki/A-Chain-comparison-to-Dapper.

Here is a real example from the ORM that I built this for: https://github.com/TortugaResearch/Chain/blob/Traits/Tortuga.Chain/Tortuga.Chain.Access/Generated/Tortuga.Shipwright/Tortuga.Shipwright.TraitGenerator/Tortuga.Chain.Access.AccessDataSourceBase.cs

Not to take anything away from Dapper (it's an excellent library), but it isn't really that much faster than EntityFramework anymore.

> EF Core 6.0 performance is now 70% faster on the industry-standard TechEmpower Fortunes benchmark, compared to 5.0.

> This is the full-stack perf improvement, including improvements in the benchmark code, the .NET runtime, etc. EF Core 6.0 itself is 31% faster executing queries.

> Heap allocations have been reduced by 43%.

> At the end of this iteration, the gap between Dapper and EF Core in the TechEmpower Fortunes benchmark narrowed from 55% to around a little under 5%.

https://devblogs.microsoft.com/dotnet/announcing-entity-fram...

Again, this isn't to take anything away from Dapper. It's a wonderful query library that lets you just write SQL and map your objects in such a simple manner. It's going to be something that a lot of people want. Historically, Entity Framework performance wasn't great and that may have motivated StackOverflow in the past. At this point, I don't think EF's performance is really an issue.

If you look at the TechEmpower Framework Benchmarks, you can see that the Dapper and EF performance is basically identical now: https://www.techempower.com/benchmarks/#section=data-r21&l=z.... One fortunes test is 0.8% faster for Dapper and the other is 6.6% faster. For multiple queries, one is 5.6% faster and the other is 3.8% faster. For single queries, one is 12.2% faster and the other 12.9% faster. So yes Dapper is faster, but there isn't a huge advantage anymore - not to the point that one would say StackOverflow has tuned their code to such an amazing point that they need substantially less hardware. If they swapped EF in, they probably wouldn't notice much of a difference in performance. In fact, in the real world where apps, the gap between them is probably going to end up being less.

If we look at some other benchmarks in the community, they tell a similar story: https://github.com/FransBouma/RawDataAccessBencher/blob/mast...

In some tests, EF actually edges past Dapper since it can compile queries in advance (which just means calling `EF.CompileQuery(myQuery)` and assigning that to a static variable that will get reused.

Again, none of this is to take away from Dapper. Dapper is a wonderful, simple library. In a world where there's so many painful database libraries, Dapper is great. It shows wonderful care in its design. Entity Framework is great too and performance isn't really an interesting distinction. I love being able to use both EF and Dapper and having such amazing database access options.

But now, EF v6.0.7.0 is improved now. I just checked https://github.com/FransBouma/RawDataAccessBencher/blob/master/Results/20220801_net6.txt

In theory this is a fair approach, till you realize that an ORM is a very complex piece of machinery that takes a lot of effort to implement (The LLBLGen Pro runtime framework is 1M lines of C# code for instance). Even falling back to a micro that performs well in most situations and can deal with the queries you need to execute (!) isn't easy. Good luck beating Linq to DB's performance (Dapper is ok, but there are faster ones, check my benchmarks, they're on github).