EF Core 9.0查询性能优化：编译标识符Lambda表达式提升Include集合填充效率

在EF Core 9.0版本中，开发团队发现了一个影响查询性能的重要问题，特别是在处理包含大量实体和Include操作的场景时。这个问题与PopulateIncludeCollection方法中标识符Lambda表达式的处理方式有关。

问题背景

在EF Core 8.0版本中，PopulateIncludeCollection方法接收的委托参数（如parentIdentifier、outerIdentifier等）是以编译后的形式传递的。而在升级到9.0版本后，这些Lambda表达式被改为以内联方式处理。这种改变虽然简化了代码结构，但却带来了显著的性能下降。

性能对比

通过基准测试可以清楚地看到性能差异：

• EF Core 8.0版本处理相同查询的平均时间为297ms（同步）和290ms（异步）
• EF Core 9.0初始版本性能下降到455ms（同步）和435ms（异步）
• 经过优化后，性能提升到363ms（同步）和352ms（异步）

内存使用方面也有明显改善：

• 初始版本分配67.92MB内存
• 优化后降至58.51MB
• 接近EF Core 8.0的52.4MB水平

技术实现细节

问题的核心在于PopulateIncludeCollection方法接收的标识符生成函数。在EF Core 8.0中，这些函数是预编译的：

Func<QueryContext, DbDataReader, object[]>

而在9.0版本中，这些函数变成了内联Lambda表达式：

(queryContext, dataReader) => new object[] { ... }

这种改变导致每次调用时都需要重新解释表达式，而不是直接执行已编译的代码，从而产生了额外的开销。

优化方案

修复方案是将这些内联Lambda表达式重新改为预编译形式。这种改变带来了以下好处：

1. 减少运行时解释表达式的开销
2. 避免重复的代码生成
3. 降低内存分配
4. 提高CPU缓存利用率

实际影响

这一优化特别有利于以下场景：

• 包含多个Include的复杂查询
• 处理大量实体数据的查询
• 高并发环境下的查询执行

版本修复

该优化已包含在EF Core 9.0.1版本中，通过恢复预编译标识符Lambda表达式的处理方式，显著提升了查询性能，使其接近EF Core 8.0的水平。

对于性能敏感的应用，特别是那些大量使用Include操作或处理大数据集的场景，升级到9.0.1版本将获得明显的性能提升。开发者在进行版本升级时，应当关注这类核心性能优化，以确保应用保持最佳运行状态。