EF Core 11 Speeds Up Split Queries by Removing Unnecessary Joins
EF Core 11 makes your split queries faster
I discovered that EF Core 11 significantly improves performance for split queries by pruning unnecessary reference navigation joins from collection queries. Previously, every collection query dragged along extra joins and order-by columns, wasting database resources. Now, the generated SQL is cleaner and more efficient, resulting in faster execution times and fewer memory allocations compared to EF Core 10.
The database does the work, throws the result away, and your query plan suffers for it.
- CodesInChaos
I think it's crazy that standard SQL has no clean way of handling nested data. It's might not fit elegantly into the relational model, but it's still a common business problem that should be addressed. At the bare minimum something like `array_agg` should be standardized.
Alternative query languages like EdgeQL show what first class support for nested data (and navigations) could look like, while the data model is still relational.
- exceptione
I don't understand the argument why `AsSplitQuery` could be more performant than a single round trip involving a multi join query. People mention data duplication and increased memory usage, but I would assume that `duplication` is just a matter of an extra pointer, not a bit-for-bit duplication of every reference to a single row.
Please enlighten me.
- kogir
I’ve always solved this with Multiple Active Result Sets and stored procedures.
Collect the data in the stored procedure with temp/in-memory tables and return minimal, non-duplicated, related result sets.
Single round trip, still accumulates results in efficient bulk batches, and allows results to be processed by the client as they stream in.
- tehlike
We need EF Core / DLINQ or equivalents for pretty much all languages.
- ComputerGuru
If op is here: you can dramatically improve the robustness and soundness of your benchmark with one simple trick: you can run old versions of ASP.NET (Core) frameworks on newer .NET runtimes with no other changes; i.e. instead of benchmarking ASP.NET 10 + EF 10 on .NET 10 vs ASP.NET 11 + EF 11 on .NET 11, you can bench ASP.NET 10 + EF 10 on .NET 11 vs ASP.NET 11 + EF 11 on .NET 11
(I always upgrade projects by first upgrading the runtime and checking everything then separately (and maybe much later!) upgrading the framework.)