Entity Framework Core is a great ORM, that recently reached version 5. Is it fast? Is it faster than it’s predecessor, Entity Framework 6, which still offers slightly more functionality? Let’s check that out.
This comparison was made by Chad Golden, comparing the performance of adding, updating, and deleting 1000 entities. The exact data and code are available on his blog: https://chadgolden.com/blog/comparing-performance-of-ef6-to-ef-core-3
The conclusions are obvious: in almost every test conducted by Chad, Entity Framework Core 3 is faster than Entity Framework 6 – exactly 2.25 to 4.15 times faster! So if performance is important to your application and it operates on large amounts of data, EF Core should be a natural choice.
Is it faster than Dapper?
Dapper is a very popular object-relational mapper and, like EF Core, it facilitates working with the database. It’s called the king of Micro ORM because it’s very fast and does some of the work for us. If we compare EF Core and Dapper, we immediately notice that the capabilities of EF Core are much greater. Microsoft technology allows you to track objects, migrate the database schema, and interact with the database without writing SQL queries. Dapper, on the other hand, maps the objects returned by the database, but all SQL commands have to be written yourself. This certainly allows more freedom in operating the database, but there is a greater risk of making a mistake when writing a SQL query. Similarly to updating the database schema, EF Core can create changes and generate a migration by itself, and in Dapper, you have to manually edit the SQL code.
There is no doubt, however, that Dapper has its supporters, mainly due to its performance. On the blog exceptionnotfound.net we can find a comparison between Entity Framework Core 3 and Dapper version 2.
As you can see, we compare 3 database reads here, where Entity Framework Core with object tracking in one case, non-tracking in the other, and Dapper’s third. Tracking changes to entities in EF Core can be turned off with the AsNoTracking() option, which makes reading operations significantly faster. More information on this test can be found here: https://exceptionnotfound.net/dapper-vs-entity-framework-core-query-performance-benchmarking-2019/
All in all – Dapper is much faster to read from the database and will certainly be comparatively fast when writing. However, it requires writing SQL queries, which can expose the developer to errors. I have personally used Dapper on several projects, and basically, only one has been dictated by performance. For the simple logic of saving and retrieving data from the database, I would use Entity Framework Core because of its simplicity and convenience in introducing changes.
10 thoughts on “Entity Framework Core – is it fast?”
Looks like you are showing the same graph twice?
Nice catch! I already fixed that 🙂
May you should also compare agains linq2db, wich has some of the ef core features (linq) but also some not (change tracking).
It has also a addon, that you can use it with EF Core together ( https://github.com/linq2db/linq2db.EntityFrameworkCore )
This looks very impressive, thanks!
Did the EF tests issue raw sql?
EF Core can check your parameters to your raw SQL for SQL injection, take a look at this page: https://docs.microsoft.com/en-us/ef/core/querying/raw-sql#passing-parameters
Tired of dapper vs EF comparisons only speed. Speed is not most important. The PROBLEM with EF is that you have no flexibility with it!
With dapper i cna write ANY query, have ANY return ith any fields i want and create simple class to those fields to be mapped..with EF you CANT! you CANT return result that has some unknown result. Lets say i want to jin 5 tables and return from 30 fields only 5 i needed the most. Lets say it’s for statistic…i CANT with EF. That’s the main weakness of EF. In older versions there was such ability with “hacks” but not now.
I think that has changed from version 3.0 of Entity Framework Core. With EF Core:
1. you can execute raw SQL and EF Core will check parameters for SQL injection
2. you can map it to your own type, without a key, that does not have to represent any existing table in DB
Please take a look at this StackOverflow question: https://stackoverflow.com/questions/35631903/raw-sql-query-without-dbset-entity-framework-core
Spot on, which is one of the main reasons I don’t use EF in anything I have control over.
Read the documentation before saying nonsense.
You can write raw sql and “return” any results from your ef queries.
With each iteration EF is getting better and better, and performance wise they will catch to dapper in no time