.NET 8中Where与Endswith性能骤降：较.NET Framework慢7倍问题咨询

你遇到的性能退化主要来自字符串EndsWith方法的内部逻辑变更，LINQ迭代器的细微差异进一步放大了这个开销，以下是具体原因和修复方案：

一、核心原因：EndsWith方法的实现差异 #

• .NET Framework 4.5.1中，EndsWith(string)默认采用当前文化比较，但针对ASCII范围内的字符串有快速路径优化，直接按字节对比，跳过了复杂的文化规则处理，单次调用开销极低。
• .NET 8重构了字符串比较的底层逻辑，默认的文化敏感比较严格遵循Unicode标准，增加了大量边界检查和文化规则适配（比如多语言字符的大小写映射、排序规则），即使是ASCII字符串，也会走通用比较逻辑，导致单次调用开销大幅上升。
• 这种变化是为了统一跨平台的字符串行为，但牺牲了部分特定场景下的性能。

二、LINQ的辅助影响 #

.NET 8的LINQ to Objects迭代器实现整体更高效，但在1000条数据的小集合场景下，每个元素都要触发一次包含EndsWith的委托调用，EndsWith本身的性能下降被累积放大，最终导致整体耗时增加7倍。

三、快速修复方案 #

1. 切换到序数比较 #

如果配置名称不需要文化敏感的比较（绝大多数配置场景都是如此），直接指定StringComparison.Ordinal或OrdinalIgnoreCase，跳过文化规则处理，性能能回到.NET Framework的水平：

return _Values.Where(w => w.Name.EndsWith(key, StringComparison.Ordinal))
              .DefaultIfEmpty(ConfigurationValue.Empty).First();

2. 替换为原生foreach循环 #

直接遍历列表，找到匹配项立即返回，避免LINQ迭代器的委托调用和额外对象分配，性能会进一步提升：

foreach (var value in _Values)
{
    if (value.Name.EndsWith(key, StringComparison.Ordinal))
    {
        return value;
    }
}
return ConfigurationValue.Empty;

3. 长期优化方案 #

如果该查询是高频调用，可以提前对_Values做预处理：

• 将名称反转后排序，使用二分查找快速定位后缀匹配项（即你提到的二分搜索方案），将O(n)的查询复杂度降到O(log n)；
• 或者构建后缀到ConfigurationValue的索引字典，实现O(1)的查询。

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