Entity Framework Core Performance Optimization

What this prompt does

This prompt drives a focused Entity Framework Core performance pass on a [dotnet_version] application backed by [database] with [entity_count] entities. It walks through N+1 detection using [logging_approach], query optimization with projection and compiled queries for [frequent_queries], change-tracking configuration, bulk operations via [bulk_library], connection management, indexing for [index_scenarios], and lazy-versus-explicit loading. Each step targets a concrete scenario like [n1_scenario] or [slow_query] rather than abstract advice.

The structure works because almost every EF Core slowdown traces back to N+1 queries or change tracking left on for read-only paths, so the prompt instruments those first. It insists on BenchmarkDotNet before-and-after numbers, because "it feels faster" is not a result you can defend. Fixing [n1_scenario] with Include(), ThenInclude(), and AsSplitQuery(), then projecting [slow_query] with Select to avoid loading unused columns, is where most of the real wins come from.

When to use it

• A page or endpoint is slow and you suspect N+1 queries behind [n1_scenario]
• A query like [slow_query] loads far more data than it needs and you want to project it down
• You are running read-only queries that don't need change tracking and want the performance back
• You need to replace SaveChanges() loops with [bulk_library] for [bulk_operations]
• You want indexes suggested and a migration generated for [index_scenarios]
• You need defensible before-and-after benchmarks rather than subjective "feels faster" claims

Example output

Expect a remediation walkthrough: how to surface N+1 queries through logging, refactored queries using Include(), ThenInclude(), AsSplitQuery(), and projection, AsNoTracking guidance with performance notes, bulk-operation code with before/after benchmarks, connection-pooling and retry configuration, suggested indexes with a generated migration, lazy-versus-explicit loading guidance, and BenchmarkDotNet tests comparing old and optimized versions.

Pro tips

• Describe [n1_scenario] precisely — "orders with items and product details for a customer list" tells the model exactly which Include and split-query strategy to apply
• Reach for AsSplitQuery() when a single Include-heavy query produces a Cartesian explosion, but benchmark it, since extra round-trips can sometimes be slower
• Add AsNoTracking to read-only paths first; it is the lowest-risk change with a real payoff, especially on large result sets
• Choose [bulk_library] deliberately — third-party bulk extensions bypass change tracking, so they are fast but skip EF's safety nets
• Always run the BenchmarkDotNet step; the model can suggest optimizations, but only measured numbers tell you which ones actually helped your workload
• Verify suggested indexes against your real query plans before adding them all, since every index adds write overhead
• Use compiled queries for [frequent_queries] that run constantly, since caching the query plan removes repeated expression-tree compilation on hot paths
• Prefer AsNoTrackingWithIdentityResolution() over plain AsNoTracking() when a read-only query returns the same entity multiple times and you need reference equality
• Profile against production-like data volumes, not a tiny dev database, because an N+1 that looks fine on ten rows is what tanks the page on ten thousand