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.

Answer

EF Core query is slow—should I use Dapper?

Mohan Veer Singh

21h

1 Entity Framework

EF Core vs Dapper

EF Core query is slow—should I use Dapper?

Insert Link

Embed YouTube Video

Table Options

Insert Image

Answers (1)