C#中String Contains与String Replace的性能测试疑问

测试场景 #

测试对比两段C#字符串处理逻辑：

// 逻辑1：先检查再替换
if (_items.Contains("M"))
{
    _items.Replace("M", "N");
}

// 逻辑2：直接替换
_items.Replace("M", "N");

使用DotNet Benchmark对带种子的不同长度随机字符串进行性能测试，得到对应结果（附测试结果图）。

核心疑问 #

• 为何字符串长度达到25字符才开始产生内存分配？
• 为何长度小于25字符时，先检查再替换的速度更快；而25字符及以上时，直接替换的性能反而更优？
  原本预期无需两次遍历的直接替换更高效，但短字符串的测试结果与预期相悖，特此求解。

问题解答 #

1. 25字符触发内存分配的原因 #

这源于.NET的**小字符串优化（SSO）**机制：

• 对于长度≤25的字符串，.NET会将字符直接存储在字符串对象本身的内部缓冲区中（而非堆上的独立数组），这类字符串的内存管理更轻量。
• Replace方法的内部逻辑是：如果遍历后未找到需要替换的字符，会直接返回原字符串的引用，不会创建新对象。对于符合SSO条件的短字符串，只要没有实际替换发生，就不会产生新的内存分配。
• 当字符串长度超过25时，字符会被存储在堆上的独立数组中。此时即使替换后字符数量不变，也需要分配新的数组和字符串对象，因此会产生内存分配。

2. 长短字符串的性能反转逻辑 #

短字符串场景：先检查再替换更优

• 短字符串的遍历成本极低，Contains和Replace的操作都在距离栈极近的SSO缓冲区完成，CPU缓存命中率接近100%，单次遍历的耗时可以忽略。
• Replace方法即使未找到目标字符，也会完成一次全量遍历。而先调用Contains的逻辑，如果字符不存在，会直接跳过后续的Replace——相当于避免了一次无意义的全量遍历，总开销略低。
• .NET对SSO字符串的Contains和Replace都有专门的精简优化路径，额外的方法调用开销几乎可以忽略不计。

长字符串场景：直接替换更优

• 长字符串的字符存储在堆数组中，遍历成本显著提升。两次独立遍历（Contains+Replace）的总CPU周期，会超过一次Replace遍历的开销——因为Replace可以在单次遍历中同时完成检查和替换操作，无需重复遍历整个字符串。
• 长字符串的缓存命中率下降，两次遍历会带来更多的内存访问开销，进一步拉大了与单次遍历的性能差距。
• 此外，Replace方法针对长字符串有批量处理的优化逻辑，单次遍历的执行效率远高于两次独立遍历的叠加。

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