EF Core 9.0 性能优化：提升 Liftable 常量解析器编译效率

在 EF Core 9.0 的开发过程中，开发团队发现了一个影响查询性能的重要问题。这个问题涉及到 EF Core 查询管道中 LiftableConstantExpressions 的处理方式，特别是在解析包含 lambda 表达式的常量解析器时出现的性能瓶颈。

问题背景

EF Core 在处理查询时，会将一些表达式转换为 LiftableConstantExpressions（可提升的常量表达式）。这些表达式在常规模式下会被编译成委托，然后执行以获取实际用于查询计划的常量值。然而，当这些表达式本身包含或本身就是委托（如 lambda 表达式）时，使用解释模式（interpretation mode）进行编译会导致显著的性能下降和内存分配增加。

性能影响分析

通过基准测试可以清楚地看到这个问题的影响：

修复前性能数据：

• 平均执行时间：487ms
• 内存分配：103.29 MB
• Gen0 垃圾回收：17000 次
• Gen1 垃圾回收：11000 次

修复后性能数据：

• 平均执行时间：约 445ms（提升约 9%）
• 内存分配：67.92 MB（减少 34%）
• Gen0 垃圾回收：11000 次（减少 35%）
• Gen1 垃圾回收：6000 次（减少 45%）

技术细节

问题的核心在于 EF Core 在处理包含 lambda 表达式的 LiftableConstantExpressions 时，默认使用了解释模式进行编译。解释模式虽然在某些场景下有其优势，但对于包含委托的表达式来说，会导致：

1. 执行速度显著变慢
2. 内存分配大幅增加
3. 垃圾回收压力增大

通过一个简化的基准测试可以清楚地展示这种差异：

// 包含lambda表达式的复杂表达式树
var expression = Expression.Lambda<Func<object, Func<object?, object?, bool>[]>>(
    Expression.NewArrayInit(
        typeof(Func<object, object, bool>),
        Expression.Lambda<Func<object?, object?, bool>>(
            Expression.Condition(
                Expression.Equal(left, Expression.Constant(null)),
                // 更多表达式...
            left, right)), prm);

测试结果显示：

• 常规编译模式：65.69 μs，分配 468.75 KB
• 解释编译模式：930.20 μs，分配 2656.25 KB

解释模式的执行时间增加了约14倍，内存分配增加了约5.7倍。

解决方案

EF Core 团队通过修改 Liftable 常量解析器的处理逻辑解决了这个问题。具体措施包括：

1. 检测表达式是否包含 lambda 表达式或委托
2. 对于包含委托的表达式，避免使用解释模式编译
3. 优化编译策略，根据表达式内容自动选择最合适的编译方式

这种优化特别有利于包含复杂条件判断和嵌套 lambda 表达式的查询场景，如多表关联查询（MultiInclude）等。

实际影响

这一优化已经在 EF Core 9.0.1 版本中发布，对于使用复杂查询的应用程序，特别是那些包含以下特征的查询：

• 大量使用 Include/ThenInclude 进行关联加载
• 查询中包含复杂的条件判断
• 使用自定义的表达式树转换

都能显著感受到性能提升和内存占用的降低。开发团队建议所有使用 EF Core 9.0 的用户升级到 9.0.1 或更高版本以获得这一性能改进。

总结

EF Core 9.0.1 中的这一优化展示了查询管道性能调优的重要性。通过深入分析表达式编译策略，并根据表达式内容选择最优的编译方式，可以显著提升 ORM 框架的整体性能。这也提醒开发者在编写复杂 LINQ 查询时，应当注意表达式树的复杂度对性能的潜在影响。