EF Core query is slow—should I use Dapper?

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.

2 Replies

Know the answer? Post it — somebody with the same question will find it here.

Yogi S6mo ago
In codes where you find slowness, you can change them to ADO.NET Codes to see if their is improvements.
Darshan Adakane6mo ago
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.