EF Core 6.0 benchmark
coderdnewbie opened this issue · 8 comments
It would be interesting to see how ef core 6. 0 does in these benchmarks, please.
Agreed :) I'll migrate it (and add llblgen pro v5.9) to it in the new year
Thanks, have a good holiday.
Thanks for doing this, the results were unexpected, even when comparing net 5 with net 6, Repodb especially. I did not expect ef core 6 to be faster than dapper.
Dapper isn't the fastest around, contrary to popular believe. I am honestly surprised EF Core 6 isn't faster than they are considering the release notes of EF Core 6 speak of a lot of performance updates.
Repodb seems to be the fastest around. The ef core 6 changes made ef core 6, 5% slower than dapper according to the techenpower benchmarks (used to be 45 to 50 percent slower) , so I expected ef core 6 to be slower than dapper. Speed is not everything the enterprise company I work for uses ef core and dapper as a hybrid using mediatr CQRS, so your benchmark was interesting to me, as we may get rid of dapper once ef core has improved again in ef core 7.
They might get faster but I doubt it, they really pushed to get as close to dapper as possible. What I find a bit surprising, as being faster than dapper isn't that hard. RepoDB is the fastest, but they do cut a corner (like Linq2DB does too): they skip null checks if the schema they get back tells them a column can't be null. This in general works, but not always. I.e. if you fetch a set from a view, you can get false positives there: if you change the nullability of a column in a table used in the view, the view's meta-data isn't updated in SQL Server, you actively have to drop/recreate the view. My LLBLGen Pro framework always tests for nullability in the columns hence it loses a bit (dapper/ef core do too). Everything is so close together btw, it doesn't really mean much what you pick, except perhaps EF or NH which are really not that fast
if you fetch a set from a view, you can get false positives there: if you change the nullability of a column in a table used in the view, the view's meta-data isn't updated in SQL Server, you actively have to drop/recreate the view.
We do encounter this in our case, we just have to call the DbFieldCache.Flush() to redownload the newly updated sets of schema. Of course, this would only work if the developers know that the schema has change in the underlying data store.
More into it, one reason why RepoDB is faster than Linq2DB is because of the additional compilation (and reusability) of the already cached Execution Contexts based on the given type (whether it is a custom or anonymous type), and of course, the fact that every layer (i.e.: Property Access, Column Access, Id Access, Identity Access) are all cached. Never know if this technique has been implemented to other ORMs but this works well if the lazy developers are used into using the Anonymous Types when passing the parameters. Atleast, it has a huge impact on this benchmark.
In the ef core 7 community stand up they said in the road map they will be doing more performance improvements, that is why I mentioned this.