Dart2Wasm 中集合展开操作缺失的虚调用优化分析

背景介绍

在 Dart 语言中，集合展开操作（spread operator）是一种方便的语法特性，允许开发者将一个集合的所有元素展开到另一个集合中。例如，{...a, ...b} 表示将集合 a 和 b 的所有元素合并到一个新的集合中。

在 Dart 编译为 WebAssembly (Wasm) 的过程中，编译器会对代码进行各种优化，其中一项重要优化是"去虚拟化"（devirtualization），即将虚方法调用转换为直接方法调用，从而提高运行时性能。

问题现象

在当前的 dart2wasm 编译器中，处理集合展开操作时存在一个性能优化缺失的问题。当编译以下示例代码时：

main() {
  final a = {1, 2};
  final b = {1, 2};
  print({...a, ...b});
}

生成的中间表示（Kernel IR）中，addAll 方法调用缺少 @vm.direct-call.metadata 注解，这意味着编译器无法对这个虚方法调用进行去虚拟化优化。

技术细节分析

正常编译流程

在 Dart VM 的编译流程中，相同的代码会经过类型流分析（TFA）阶段，该阶段能够识别出 addAll 方法调用的具体实现，并添加相应的直接调用元数据：

[@vm.direct-call.metadata=dart._compact_hash::_Set.addAll]

这使得 VM 能够生成更高效的本地代码，避免了虚方法调用的开销。

Wasm 编译差异

然而在 dart2wasm 的编译流程中：

1. 生成的 Kernel IR 缺少去虚拟化元数据
2. 最终产生的 Wasm 代码使用 call_indirect 进行间接调用
3. 缺少类型特化信息（如 InterfaceType(int)）

这种差异导致了以下性能影响：

1. 间接调用比直接调用有更高的开销
2. Wasm 引擎难以进行进一步的优化
3. 缺少类型信息可能导致额外的运行时检查

优化建议

从技术实现角度来看，可以采取以下改进措施：

1. 增强类型分析：在 Kernel 生成阶段收集更多的类型信息
2. 传播调用目标信息：对于已知的具体实现（如 _Set.addAll），添加直接调用元数据
3. 特化集合操作：针对常见集合类型（Set/List/Map）的展开操作生成专用代码路径

潜在影响

修复这个问题将带来以下好处：

1. 提升集合操作的执行效率
2. 减少生成的 Wasm 代码大小（避免间接调用表项）
3. 为后续优化（如内联）创造更多机会

结论

Dart2Wasm 编译器中集合展开操作的虚调用优化缺失是一个典型的编译器优化机会。通过完善类型分析和调用目标解析，可以显著提升这类常见操作的运行时性能。这个问题也反映了从 Dart VM 到 Wasm 的编译管道中优化传递的一致性挑战，值得在编译器架构层面进行更系统的审视和改进。