Blazor WebAssembly与WPF的C#代码性能差异及优化咨询

问题背景 #

团队正从C#/WPF迁移至Blazor/WebAssembly开发大型复杂UI应用，原型开发中发现循环内C#代码执行性能远低于预期，测试用例如下：

List<MyClass> classList = new List<MyClass>();
int counter = 10000;
for (int i = 0; i < counter; i++)
{
    var c = new MyClass();

    c.Prop1 = "test";
    c.Prop2 = 1;

    classList.Add(c);
}

public class MyClass
{
    public string? Prop1 { get; set; }
    public int? Prop2 { get; set; }
}

同一硬件、.NET 8环境下的性能对比（10次测试平均耗时，单位：ms）：

核心性能差距：

• 调试时Blazor性能约为WPF的1/50，远超常规调试开销
• 发布后Blazor性能仍仅为WPF调试版的1/5

优化方案 #

1. 提升Blazor调试时的性能 #

• 切换到Release模式调试：Debug模式下Blazor WASM默认生成未优化的IL解释代码，改用Release配置启动调试，会启用部分编译优化，大幅降低调试开销。
• 关闭调试热重载：热重载会注入代码变更检测逻辑，关闭后可减少调试过程中的性能损耗（在Visual Studio设置中禁用"启用热重载"选项即可）。
• 启用分层编译：在项目文件中添加<TieredCompilation>true</TieredCompilation>，调试时高频执行的代码会被编译到优化执行层，提升循环类代码的运行速度。
• 精简断点数量：过多断点会触发额外调试检查，只保留必要断点可减少执行延迟。

2. 让C#代码执行性能接近原生 #

• 启用WebAssembly AOT编译：这是提升发布版性能最关键的手段，将C#代码直接编译为WebAssembly原生指令，替代IL解释执行。在项目文件中添加：

  <PropertyGroup>
    <RunAOTCompilation>true</RunAOTCompilation>
  </PropertyGroup>
  

  注意：AOT会增加发布包体积，需根据项目需求权衡。
• 优化代码结构：
  • 预先初始化集合容量：将new List<MyClass>()改为new List<MyClass>(counter)，避免循环中频繁扩容的开销。
  • 移除不必要的可空类型：若Prop1和Prop2不会为null，改为public string Prop1 { get; set; }和public int Prop2 { get; set; }，减少运行时空检查和装箱操作。
  • 复用常量字符串：将"test"提取为类级常量，避免循环中重复创建字符串实例。
• 启用Native AOT（.NET 8+）：对性能要求极高的场景，使用Native AOT编译（项目文件中设置<PublishAot>true</PublishAot>），编译后性能更接近原生，但发布体积会进一步增大。
• 保留分层编译：发布时维持<TieredCompilation>true</TieredCompilation>，让高频代码自动切换到优化执行层。

其他开发者的经验 #

不少从桌面端迁移到Blazor WASM的开发者都遇到过类似性能差距，尤其是Debug模式下的IL解释执行瓶颈。通过启用AOT编译、优化代码结构、调整调试配置后，发布版性能可大幅提升，部分场景下能接近WPF原生执行效率；调试模式下的性能差距虽无法完全消除，但通过Release模式调试等手段可将差距控制在可接受范围内。

内容的提问来源于stack exchange，提问作者Luqqu