为何Span<T>的迭代/索引器性能比Array慢？

两种实现对比 #

原始数组版本 #

// 伪代码
public static void MyMethod(int length)
{
    char[] output = new char[length];
    for (int i = 0; i < length; i++)
    {
        output[i] = DoStuff(i);
    }
}

Span优化内存版本 #

public static void MyMethod(int length)
{
    Span<char> output = stackalloc char[length]; // 仅修改此行
    for (int i = 0; i < length; i++)
    {
        output[i] = DoStuff(i);
    }
}

问题现象 #

在.NET 8环境下通过BDN基准测试发现：改用stackalloc的Span后，内存占用降低了5倍，但性能反而比数组版本慢20%。原本预期Span的栈分配应该带来性能提升，实际却相反。

可能的原因 #

• 边界检查差异：数组是固定长度类型，当循环变量i的范围明确与数组长度绑定（比如i < length，而length就是数组创建长度），JIT编译器可以智能消除循环内的所有边界检查；而Span的长度由运行时参数决定，JIT对其边界检查消除的优化力度目前不如数组，导致每次访问output[i]都要执行额外的边界检查逻辑。
• JIT优化成熟度：数组作为.NET基础类型，JIT编译器对其内存访问、边界检查的优化逻辑已经非常成熟；而Span是相对较新的类型，针对动态长度场景的优化覆盖还不完善。

尝试过的无效方案 #

使用unsafe代码结合fixed char*直接操作指针，性能没有明显提升——说明即使跳过Span的封装，边界检查或其他底层开销依然存在，或者指针操作本身的优化空间有限。

可行的优化方向 #

1. 用Unsafe类跳过边界检查
   通过Unsafe.Add直接操作Span的内存起始引用，绕开Span索引器的边界检查：

   using System.Runtime.CompilerServices;
   
   public static void MyMethod(int length)
   {
       Span<char> output = stackalloc char[length];
       ref char startRef = ref MemoryMarshal.GetReference(output);
       for (int i = 0; i < length; i++)
       {
           Unsafe.Add(ref startRef, i) = DoStuff(i);
       }
   }
   

   注意：必须确保循环不会越界，否则会引发内存访问错误。

2. 将length设为编译时常量（场景允许时）
   如果length的值在编译时就能确定，JIT可以对Span的边界检查进行完全消除，性能会接近甚至超过数组版本。

3. unsafe上下文直接操作指针
   获取Span的底层指针，通过指针索引直接赋值：

   public static unsafe void MyMethod(int length)
   {
       Span<char> output = stackalloc char[length];
       char* ptr = (char*)output.UnsafePointer;
       for (int i = 0; i < length; i++)
       {
           ptr[i] = DoStuff(i);
       }
   }
   

   此方式属于不安全操作，需严格保证索引不越界。

补充说明 #

社区讨论中也存在类似案例，证实了边界检查是Span性能不如数组的核心原因，在部分场景下局部数组的性能确实会优于Span。

内容的提问来源于stack exchange，提问作者Alex from Jitbit