为何LINQ Aggregate处理类/结构体包装的基础类型集合远慢于原生类型？

1. 额外的属性访问开销：原生double版本直接操作值本身，而封装后的结构体/类版本需要多一步Value属性的访问操作，虽然只读属性的开销很低，但在你这个每秒数亿次操作的热路径下会被明显放大。其中类版本还要额外增加一次托管堆对象的解引用操作，所以耗时比结构体版本更高。
2. 值拷贝开销：LINQ的Aggregate方法每一次迭代调用委托时，都会对值类型参数做一次拷贝。原生double只有8字节，拷贝开销极低；而自定义结构体哪怕只包含一个double字段，拷贝操作的指令成本也比原生double略高，如果后续新增更多结构体字段，开销还会进一步上涨。
3. 委托调用与优化限制：你当前的测试场景相当于执行了30万次*2000次 = 6亿次委托调用。原生double的委托逻辑非常简单，JIT编译器很容易做内联优化，几乎可以抹除委托的间接调用开销；而自定义类型的委托多了属性访问逻辑，内联难度提升，最终执行的指令数明显更多，耗时自然翻倍。

• 局部缓存目标值：把你当前代码中委托内用到的searchStructFoo.Value/searchClassFoo.Value提前提取为栈上的局部double变量，避免每次比较都要访问外部变量的属性，改完就能获得明显的性能提升。
• 手写遍历循环替换LINQ Aggregate：这是性价比最高的优化方案，直接去掉委托调用的开销，手写逻辑示例如下：

double target = searchStructFoo.Value;
StructFoo closest = _structFooList[0];
double minDiff = Math.Abs(closest.Value - target);
// 从第二个元素开始遍历
for (int j = 1; j < _structFooList.Count; j++)
{
    var current = _structFooList[j];
    var currentDiff = Math.Abs(current.Value - target);
    if (currentDiff < minDiff)
    {
        minDiff = currentDiff;
        closest = current;
    }
}

该写法在你的测试场景下性能会比Aggregate版本高1~2倍，和原生double的手写循环性能几乎一致。

• 有序列表用二分查找：如果你的业务场景中待查找的列表是有序的，直接用二分查找替代遍历即可，时间复杂度从O(n)降到O(logn)，你30万次查找的总耗时会直接降到几十毫秒甚至更低，性能提升远高于循环优化。
• 优先用只读结构体：你当前用的readonly struct已经是值类型封装的最优方案，比普通结构体少了防御性拷贝的开销，不要改成普通结构体。

不需要一概而论：如果是低频调用的非核心路径，LINQ的可读性优势远大于可忽略的性能开销，完全可以正常使用。但如果是类似当前高频调用的热路径，LINQ的委托、泛型封装开销会被放大，这种场景下更适合手写原生循环获得最优性能。

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