EF Core query is slow—should I use Dapper?

Question

EF Core vs Dapper

Yogi S · Answer

In codes where you find slowness, you can change them to ADO.NET Codes to see if their is improvements.

Darshan Adakane · Answer

Hello Mohan I would probably stick to EF core and would not jump to Dapper yet. In 99% of the cases where someone says “EF Core is slow”, after 10 minutes of profiling it’s one of these five stupid-easy fixes that gives you 3–10× speedup: 1. Forgot .AsNoTracking() on a read-only query ? biggest win, often halves time + memory 2. Selecting full entities instead of projecting with .Select(new { ... }) ? kills it on wide tables 3. N+1 happening silently (lazy loading or missing .Include()) ? turns 1 query into 100+ 4. Running the same query in a hot loop without compiled query ? EF re-compiles every time 5. No proper index on the filter/join columns (most common DB-side issue) Only if you’re still unhappy (and profiler shows EF materialization / expression tree overhead is the actual culprit), then yeah — sprinkle Dapper on the 2–3 hottest read endpoints. But rewriting the whole app to Dapper because one report is slow? Usually not worth the pain. Let me know if you were able to figure it out and what was the outcomes. Hope this helps Thanks for reading and if this helped you please mark this as Accepted Answer.

EF Core query is slow—should I use Dapper?

Insert Link

Embed YouTube Video

Table Options

Insert Image

Answers (2)