遍历数组Span何时快于数组本身？对应.NET版本是多少？

问题背景 #

Nick Chapsas在近期视频中指出，List<T>.Find方法存在未优化的情况，原因是该方法直接遍历内部数组而非数组的Span，其核心代码如下：

public T? Find(Predicate<T> match) {
    if (match == null) {
        ThrowHelper.ThrowArgumentNullException(ExceptionArgument.match);
    }

    for (int i = 0; i < _size; i++) {
        if (match(_items[i])) {
            return _items[i];
        }
    }
    return default;
}

此前根据Stephen Toub关于Span的博客内容，普遍认为遍历Span的速度最多与数组相当，不会更快，博客原文提到：

汇编代码之所以如此相似，部分原因是消除了边界检查。另外，JIT会将Span索引器识别为固有函数，即JIT会为该索引器生成特殊代码，而非将其实际IL代码转换为汇编。
所有这些都表明，运行时可以对Span应用与数组相同的优化，使Span成为高效的数据访问机制。

核心问题解答 #

1. 何时公认Span遍历速度可与数组相当甚至更快？ #

从Span首次引入的** .NET Core 2.1 **版本开始，JIT编译器就对Span的索引器实现了固有函数处理，同时支持边界检查消除等关键优化，此时Span的遍历性能就已经能和原生数组持平。

所谓“更快”的场景并非纯遍历操作本身，而是Span在避免数组拷贝、处理内存切片等场景下的间接性能优势：比如当需要操作数组的一部分时，Span无需创建新的数组实例，直接指向原数组的内存区域，减少了内存分配和拷贝的开销，从而整体表现更高效；而在纯遍历数组的场景中，Span和原生数组的性能几乎没有差异。

2. 是否存在仅适用于Span、无法应用于数组的JIT优化？ #

多数核心JIT优化（如边界检查消除、循环展开、向量化）对数组和Span是通用的，不存在专门只给Span的独占优化。但Span的设计特性使其在某些特殊场景下能更充分利用现有优化：

• 当处理非托管内存、栈内存或数组切片时，Span的内存访问模式更紧凑，JIT能更高效地生成汇编代码；
• Span的索引器是值类型，避免了引用类型的额外开销，但这属于类型设计优势而非JIT专属优化。

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