Entity Framework Core vs Dapper Performance in 2023

Hello everybody I'm Nick and in this video I will compare Entity Framework Core's and Dapper's performance to see which one is faster and more memory efficient and by how much. The results were actually pretty interesting.

Don't forget to comment, like and subscribe :)

Social Media:

#csharp #dotnet

[nickchapsas]

For those asking about Compiled Queries, I originally had them in my notes but I totally forgot to record them. Sorry for that.

That's what getting a single item by the PK using compiled queries would look like:
| EF_Single | 34.855 us | 6.8 KB |
| EF_Single_Compiled | 10.325 us | 2.75 KB |
| Dapper_GetById | 7.302 us | 2.23 KB |

That's what filtering would look like with compiled queries:
| EF_Filter | 32.77 us | 7.84 KB |
| EF_Filter_Compiled | 12.98 us | 4.24 KB |
| Dapper_Filter | 12.60 us | 3.84 KB |

As you can tell, it's way closer to Dapper in speed and memory.
Do keep in mind that they are NOT free or a silver bullet. Again, sorry for not adding that part in the video. I will be making a dedicated video on them to address this.

[PauloDanielCarneiro]

I would love to see a video about why AsNoTracking is slower and also less memory efficient.

[clementdurazzo]

Interesting results… we use EF as a SelectOnly provider to dynamic request. As we dont want to “build” a query dynamically, we use EF to built if for us. The rule is : if it’s a static request : Dapper, EF otherwise.
I would be very interested to see how you operate with dapper and dynamic query that can change with querystring filter for instance.

[kconfesor]

To be honest that's pretty impressive, EF core is really good as of now, but i don't think it will ever match Dapper in performance/efficiency. Simply because EF Core has way more stuff to offer that makes your life easier, i don't mind if it's 20us slower than Dapper

[cyrildouglas]

I was waiting for you to compare the new EF methods such as ExecuteDelete and ExecuteUpdate with dapper methods, these two new methods are insanely fast compared to the old way of EF core.

[gilbes]

EF for writes is amazing. The data modeling and migrations is superb. For reads, it depends. Writing non-trivial efficient queries is hard enough. Adding the LINQ abstraction over that query generation and hoping the server's query optimizer will like what EF produced is too much of a headache. I appreciate that EF added raw SQL as a first class feature, but if I am going that route I prefer Dapper. The hybrid approach give you the best of both worlds with the fewest headaches.

[CharlesBurnsPrime]

Your SSD may be able to do 5 GB per second in long, sustained transfers of large files, but database transactions are typically very small. The usage pattern and performance characteristics are very different. For a better idea of database performance, look at its rated IOPS.

[isnakolah]

Dapper is undoubtedly faster but for most projects, this performance is not worth it compared to the effort to write this queries. Especially when you have projections by automapper, it's just very convenient and clean

[mslucass]

If you use EF could you create a nice course for EF?

[mike]

Hi Nick
It would be very exciting to know why AsNoTracking is slower and also less memory efficient....
Great videos, thanks for that!

[KooshanAbedian]

You should have also compared EFcore raw sql APIs for queries as well. I'm also wondering how far could you push it using compiled queries, compiled models, using context pooling, customizing transactions isolvl to read uncommitted, using assplitquery, MARS, or AsyncEnumerable APIs.
I think this video deserves a part 2. Thanks anyway. Keep up your great work. Always love and appreciate your content.
P.s. please explain the asnotracking thing.

[diadetediotedio]

I think when EF Core stops using reflection entirely and move into source generators we would see a huge drop in the memory consumption

[lupf]

Thanks for the video. Just one remark, before everybody runs away to refactor the data access layer and switch from EF to Dapper: Can we let it sink in for a moment, that these tests provide measurements using nanoseconds or microseconds? I'd suspect, that the actual overhead introduced by the ORM is mostly insignificant, as soon as your ORM of choice has to speak with something that's not living on localhost?

[berathebrain]

I switched from EF to Linq2DB and never looked back. I would love to see a comparison in speed and ease of use between these 2.

[IvanRandomDude]

How big of an impact on overall web app speed this has in real world setup (the database is on remote server)? We are still talking about micro seconds here. Gaining extra 30 micro seconds of speed when added to something like 20-50ms on top of the time needed to execute a query over network and receive the response is almost not noticeable. 20ms + 10/1000ms vs 20ms + 40/1000ms. It ends up 20.01 vs 20.04 which is not that drastic at all. To me memory allocation is bigger factor here. If I can save 8-10 kb of memory per request that is huge, especially if we have high traffic.

[alexbarac]

We decided, when implementing CQRS, to use EFCore for commands and Dapper for queries, it seems we made the right choice.

There's something that is totally left away in this tests, which is initialization... while dapper has none, creating the DbContext will take its time, and that, specially when you're working with AWS Lambda or Azure functions is a very important performance hit in the cold start cases...

[xentricator]

I wonder how using Compiled queries would influence the EF Core results. Maybe an idea for another video Nick?

[Unrurien]

Very much interested in seeing more about ef core. Particularly the AsNoTracking() and AsSplitQuery() options espesially on objects with complex relations

[amirhosseinahmadi]

You should've used EF Core's new `ExecuteUpdate` and `ExecuteDelete` methods for the delete and update benckmarks.