.NET 7中WebAssembly环境下泛型+Lambda为何性能低下？

问题背景 #

非泛型高性能实现 #

public static int SumInt(int[] vals)
{
    int sum = default;

    for (int i = 0; i < vals.Length; i++)
        sum += vals[i];

    return sum;
}

针对相同输入，该方法在WebAssembly（WASM）中运行耗时约70毫秒。

泛型低性能实现 #

为支持更多数值类型，编写了泛型求和方法，并封装了特定类型的调用入口：

public static T Sum<T>(T[] vals, Func<T, T, T> add) where T : struct
{
    T sum = default;

    for (int i = 0; i < vals.Length; i++)
        sum = add(sum, vals[i]);

    return sum;
}

// 整数类型调用封装
public static int Sum(int[] vals) => Sum(vals, (x, y) => x + y);

// 其他数值类型调用封装
public static float Sum(float[] vals) => Sum(vals, AddOp);
public static double Sum(double[] vals) => Sum(vals, AddOp);

相同输入下，该泛型实现耗时约1000毫秒，但在普通.NET应用中，两种实现性能几乎无差异。

性能差异的核心原因 #

1. 委托调用的不可内联开销：非泛型方法中的sum += vals[i]是直接的硬件加法指令，而泛型版本每次循环都要执行一次Func<T,T,T>委托调用。在WASM的AOT（提前编译）模式下，编译器无法像普通.NET的JIT那样将委托调用内联为直接加法，循环次数越多，累积的开销越明显。
2. WASM的AOT优化限制：.NET WASM通常采用AOT编译，泛型方法结合委托时，AOT编译器无法针对具体实例化的类型（如int）进行特化优化，导致委托调用的额外开销无法消除；而普通.NET的JIT可以在运行时针对具体泛型实例生成优化后的机器码，抹平性能差距。
3. 值类型的调用传递开销：虽然T是值类型，但委托调用时的参数传递在WASM的调用约定下会产生额外的栈操作或复制，进一步放大循环中的性能损耗。

优化方案 #

方案1：使用.NET 7+的INumber<T>接口（推荐） #

利用.NET 7引入的System.Numerics.INumber<T>统一数值接口，直接在泛型方法中执行加法操作，彻底避免委托调用：

using System.Numerics;

public static T Sum<T>(T[] vals) where T : struct, INumber<T>
{
    T sum = T.Zero;
    for (int i = 0; i < vals.Length; i++)
    {
        sum += vals[i];
    }
    return sum;
}

这种方式下，编译器能针对具体数值类型生成直接的加法指令，WASM的AOT编译器也能进行有效优化，性能接近非泛型实现。同时自动支持所有实现INumber<T>的数值类型（int、float、double等），无需手动编写各类型的封装方法。

方案2：使用.NET 6+的静态抽象接口 #

如果基于.NET 6开发，可以通过静态抽象接口定义加法逻辑，同样避免委托开销：

// 定义静态抽象加法接口
public interface IAddable<T> where T : struct
{
    static abstract T Add(T left, T right);
}

// 为int类型实现接口
public struct IntAddable : IAddable<int>
{
    public static int Add(int left, int right) => left + right;
}

// 为float类型实现接口
public struct FloatAddable : IAddable<float>
{
    public static float Add(float left, float right) => left + right;
}

// 泛型求和方法
public static T Sum<T, TAddable>(T[] vals) 
    where T : struct 
    where TAddable : IAddable<T>
{
    T sum = default;
    for (int i = 0; i < vals.Length; i++)
    {
        sum = TAddable.Add(sum, vals[i]);
    }
    return sum;
}

// 调用示例
public static int Sum(int[] vals) => Sum<int, IntAddable>(vals);
public static float Sum(float[] vals) => Sum<float, FloatAddable>(vals);

该方案需要为每个数值类型编写对应的接口实现，不如INumber<T>简洁，但兼容性更好（支持.NET 6）。

方案3：使用Source Generator（代码生成） #

通过.NET Source Generator在编译时自动生成各数值类型的非泛型求和方法，既保证极致性能，又避免手动重复编码。例如编写一个Source Generator，自动扫描项目中的数值类型，生成类似SumInt、SumFloat的非泛型方法，同时提供统一的泛型入口（内部调用自动生成的非泛型方法）。

这种方式的性能与手动编写非泛型方法完全一致，同时自动维护多类型支持，适合需要极致性能且基于旧.NET版本的场景。

总结 #

WASM环境下泛型+委托的性能问题核心是委托调用无法被AOT编译器有效优化，而普通.NET的JIT能消除这部分开销。通过使用.NET 7+的INumber<T>接口、静态抽象接口或Source Generator，即可在支持多类型的同时保证WASM中的性能，避免代码重复。

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