Skip to content

Is Entity Framework Core 2.0 Faster? Let’s test a new version

With the Entity Framework Core 2.0 more performative, I resolved to make a performance test. I want to see if the new version got better

.NET Core 2.0 is in production now with many things improved in relation to the .NET Core 1.X. One such improved thing is Entity Framework Core. Thinking about that, I resolve to make a benchmark to see its performance.

Those who do not know the Dapper, I recommend seeing this project. It is a little ORM, It does not do all that the Entity Framework and NHibernate do, but its query is very fast. In the last years is common to see a project with an ORM and the Dapper to optimize the query.

Coming back to benchmark, I did something silly, I created the product and category entities, being that a product has a category.

An observation, I am not a specialist in benchmark or measure code performance, but I liked this package to see the performance. And that is why I am using a package called benchmarkdotnet

The idea is simple, comparing the insertion, query and query with filter. Of course, that that I make comparing Entity Framework Core 2.0 with Dapper.

Below you see the finish result.

The explication of each method,

  • EfInsert e DapperInsert: EfInsert is used by EF and DapperInsert is used by Dapper. The methods insert the data.
  • EfSelect e DapperSelect: EfSelect is used by EF and DapperSelect is used by Dapper. The methods query in the database all entities.
  • EfSeletWithFilter and DapperSelectWithFilter: EfSelectWithFilter is uded by EF and DapperSelectWithFilter is used by Dapper. The methods query in the database all products where the category name is “Games”.

Note that in all demonstration the Entity Framework Core 2.0 won. This is good, show that the Microsoft team is really fulfilling with what said about bringing a .Net Core with high performance.

Whose that still has doubt in relation to use or not the Entity Framework Core 2.0, I believe that now it is a strong option, starting by performance. I created a course that approaching the Entity Framework Core 2.0, following the link.

If you would like to analyze my benchmark and give me feedback, following the link.

Ok Guys, I hope to help you and good week.


Published in.Net Core


  1. Lorenzo Isidori Lorenzo Isidori

    In my opinion you are comparing two things of different nature. Maybe your results can be intresting if you compare EF Core2.0 with EF6, or another ORM. Anyway, at least in the previous version of EF, the troubles begin when the context grow up. If the context is bigger than 2 entities I bet your performances change a lot. This is like an “Hello world”.

    • stephanybatista stephanybatista

      Ok, thanks!

  2. João Simões João Simões

    Great benchmark. I haven’t touched the new EF Core 2, but I find it very strange that dapper is slower. Soon I’ll give it a try.

    Despite that, I have some suggestions:

    First, in the inserts, with Dapper you are accessing the database twice per run while EF is only going a single time on save changes. This should be changes into a single query for Dapper to make both equal.

    Second, remove the console writes in the select tests. Things like buffers and other stuff can affect the test in unpredictable ways. Returning the list count should be enough to be sure the compiler runs the code as expected.

    And third, while I’m not completely sure, but the connections may be the performance problem for Dapper because EF uses a new pool for DB Context creation while each time you are testing Dapper, even if the connection is from the pool, it isn’t completely optimized. My suggestion would be creating the connection and DB Context a single time and reusing them for each run method invocation (they are serialized, so concurrency shouldn’t be a problem) or you create DB Contexts and use its connections for Dapper tests.

    • stephanybatista stephanybatista

      Thanks, I liked and I will try.

  3. Kishore Kishore

    Nice article

  4. Michael Pendon Michael Pendon

    I have created an ORM with the benchmark of Dapper from the start. The reason is, we would like to simplify everything and implement a more SOLID approach when using the lightweight ORM.

    We are processing billions of data in our company and being with Dapper is good, however, the Development is tremendously scattered and tedious even organizing the design with a good structures. With Dapper, we need to right everything with SQL even in a simple steps of retrieving the data.

    My initial step solution is to create a more organized and more memory-managed lightweight ORM same as Dapper (in fact, much faster than Dapper now). For us to react more faster in the future, we have made this library a Repository-based approach, and also with the same capacity as Dapper when it comes to the connection objects.

    Feel free to contact me if you want to test the performance. But for now, we only supported the .Net Framework and not the .Net Core, but it is far awesome. But we do not need to be biased, until some expert says.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *