为何Linq性能远低于非Linq实现？实测差距达约3000倍

哇，这性能差距确实有点夸张啊！从你给出的测试数据来看，Linq实现耗时26667ms，而GetRange仅用了9ms，足足慢了3000倍。这种级别的差异肯定不是Linq本身的常规开销导致的，大概率是你的Linq写法没利用到集合的底层优化，或者犯了一些常见的Linq效率错误，我来帮你拆解一下核心原因：

1. List.GetRange的底层天生高效 #

List<T>.GetRange是List类的原生方法，它的实现完全是为性能优化设计的：

• 直接操作List内部的底层数组，不需要遍历整个大集合来筛选元素
• 内部用Array.Copy完成数据复制，这是CLR级别的高效内存操作，几乎没有额外开销
• 时间复杂度是O(k)，这里的k是你要获取的元素数量，而不是原集合的总大小（100万）

2. 你的Linq实现大概率踩了效率大坑 #

结合你的测试参数（100万元素、步长100），最可能的情况是你的Linq写法犯了以下错误：

错误写法示例：多次Skip+Take #

如果你的Linq代码是类似这样的：

var result = new List<int>();
for (int i = 0; i < 1000000; i += 100)
{
    result.AddRange(bigList.Skip(i).Take(1));
}

这就会导致**O(n²)**的时间复杂度：每次Skip(i)都会从头遍历到第i个元素，100万/100=10000次循环，每次平均遍历50万元素，总操作量直接拉到50亿次，耗时暴增就完全解释得通了。

其他可能的低效点 #

• 全量遍历筛选：如果用Where((item, index) => index % 100 == 0)，虽然是O(n)时间复杂度，但还是要遍历100万元素，而GetRange如果是取连续块的话，根本不需要遍历全量元素
• 额外对象与GC开销：Linq的每个运算符（Where/Skip/Take）都会生成新的枚举器对象，每次迭代都会产生小的GC压力，累积起来也会影响性能
• 重复枚举：如果没有及时调用ToList()/ToArray()固化Linq结果，多次枚举会导致重复遍历原集合，进一步放大耗时

3. 兼顾Linq简洁性与性能的优化方案 #

如果想保留Linq的语法简洁，同时接近GetRange的性能，可以直接利用List的索引器（O(1)访问）结合Enumerable.Range：

var step = 100;
var result = Enumerable.Range(0, bigList.Count / step)
                       .Select(i => bigList[i * step])
                       .ToList();

这种写法的时间复杂度是O(k)，和GetRange一样高效，既用到了Linq的简洁，又避免了不必要的遍历开销。

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