Making Entity Framework Core As Fast As Dapper

Hello, everybody, I'm Nick, and in this video, I will show you how you can use Entity Framework Core's Compiled Queries to achieve very similar performance to Dapper. This technique optimizes both speed and memory; the results are remarkable.

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

Social Media:

#csharp #dotnet

[sirmaelstrom]

It would be really valuable imho to see more complicated examples, not just for performance reasons but because I'm just very curious about how more complexity might change any of your approaches or design considerations in something that is closer to real world scenarios. Sometimes I come away from the videos and courses learning a lot, but not necessarily seeing how my design could really look like in a larger picture.

[danielgilleland]

Yes, a follow-up video of more complex queries would be helpful, as it will paint a clearer picture for those looking to choose between Dapper & EF Core.

[RasmusFjord]

Dear Nick, i love your videos and just became a patreon because of this. I love these small videoes with ready to use stuff, 1 focus, which makes it easier to implement on an every day to day basis! Thanks for your content!

[snapman]

The fact that EF doesn't automatically do AOT compile for queries is really astonishing.

[GlassScissors]

Hi Nick, thank you for the Benchmarks! Great information as always :) Please make a video on more complex queries. Take care and enjoy the Easter Holidays.

[Shadow_Playr]

Amazing video as always Nick.

In past we moved project from EF to sql procedures (this required lot of business logic rework). Performance hit was huge from EF for us, but good to know of things keep improving from EF Core.

[dcuccia]

Nick, this is excellent content, thank you. This feature gives me the best of both worlds - the convenience and feature set of EF core, and the performance where it's needed. Also interested in your thoughts on the new EF Core 8 raw SQL queries for unmapped types, in the same context of opt-in for squeezing performance, and what the limitations or gotchas are. Thanks!

[valentinnikolov]

Nick, continue with those videos.
They are super interesting. Thanks for debugging it.

You are a star!

[DiomedesDominguez]

In 2013 I needed to used compiled queries for a Windows Phone application, something like you did to cache the queries to a local database. I'm glad to see them again in the wild.

[expertreviews]

top drawer video... A big YES for follow-up video of more complex queries like joins etc... Once again you're putting out awesome content Nick!!!! My fav Youtuber and trainer

[isachellstrom]

Test with even more and bigger advanced queries please. Love you and your content! also very intrigued about ef vs dapper in medium to large applications.

[VitalyPavluk]

Nice !!! Please keep continue with series of EF vs Dapper!
I use EF alot but still don't know all its perf aspects
thank you

[andersborum]

As compiled queries were readily available in LINQ to SQL, it's interesting to see developers on EF Core disregarding the use of compiled queries (nor even questioning whether it exists at all, leaving valuable CPU cycles on the floor). Basically, all it takes is curiosity and peeking at the mechanism that translates C# based LINQ queries to SQL, and the subsequent materialization of data to typed objects. That path should lead to questions on whether the continuous translation could be omitted (i.e. cached, parameterized), and thus end with the discovery of compiled queries.

As a freelance consultant, absence of compiled queries on contracted projects are usually the norm, and it's usually a quick win to implement.

Disclaimer: compiled queries are more heavy during application start-up, obviously, as the expression tree needs to be evaluated and translated, but they're clear winners for the majority of applications that are online for hours or days on end. Nick mentions this as well, but given the amount of memory available to app domains these days, compiled queries should be the default approach imo.

[logank.]

Personal opinion on this kind of subject is that if you have the experience to know when something like compiled queries is necessary then go for it. Otherwise I tend to go with the "it isn't a performance issue until it is one." If something becomes a performance bottleneck for one reason or another then use a profiler to find where it is, diagnose the root cause, and then optimize for your needs. I just ran into this one in a project I'm helping with where they were rending ~150 (at most) extremely simple polygons (7 or 8 points at most). I wrote a conversion function that would give you the polygon when you asked for it. In areas of the program that needed a polygon I would ask for one and do with it what I needed. Performance was perceptively instantaneous and memory usage was well within acceptable parameters.

The argument was around the idea of "we should cache it on the way in so it is calculated and created once at most. It'll perform better that way." I benchmarked it (with DotnetBenchmark of course) and doing the operation that produced a polygon 3x as complicated than needed an insane number of times (they would never get close to) the results were 7.4ms and 10MB of heap allocation. In some contexts that is insanely slow. In this particular context it is insanely fast. Unfortunately it was multiple days worth of discussion even after I shared my results. I'll never get that time back that everyone could've spent doing more productive things.

TL;DR
If your experience tells you this is the right time to do something more performant have at it. If you don't have the experience then focus more on how clear your intent is being expressed. Sometimes code that is easier to read and understand is worth more than code that executes faster. To steal a quote I read from someone somewhere on YouTube "if your code doesn't work I don't care how fast it doesn't work."

[manishmayekar]

Hi, Can you make scenario where stored procedure from database side is integrated into Entity Framework

[alexandregiaccheri]

I'd love to see some examples of more complex expressions with benchmarks!

[MatthewCrawford]

Looks like an awesome addition to make to the EF repository wrapper

[ricardomlourenco]

Awesome video. We definitely need the more complex scenarios.

Also can you create a comparison calling a Stored Procedure?

[GachiMayhem]

Very good, thanks Nick! Now waiting for AsNoTracking() explanation)

[franciscovilches]

My team keeps track of the top slowest queries. Another great tool to have under our belt to optimize these.