自定义DataReader性能远低于.NET内置StringReader的原因问询

性能差异的核心原因 #

• 字符串边界检查消除的差异
  C#中访问字符串的索引位置时，JIT默认会自动插入边界检查逻辑避免越界访问。你自定义的DataReader属于普通用户代码，哪怕你已经手动判断了pos < length，JIT也不会基于这个判断自动消除后续source[pos]的内置边界检查，相当于每调用一次Peek/Read，都会多执行一次隐式的边界校验。
  而.NET内置的StringReader属于BCL核心库的受信任代码，JIT会直接信任它自己实现的边界判断逻辑，省略source[pos]的内置边界检查，仅此一项就会减少一半的重复校验开销。
• JIT优化力度的差异
  内置StringReader是密封类，且属于运行时优先优化的核心类型，JIT会对Peek、Read这类小方法做强制内联，完全消除方法调用的开销。普通用户自定义类默认不会享受到这种优先级的激进优化，哪怕手动给类加sealed关键字，优化程度也会弱于内置类型。
• 测试逻辑的额外放大效应
  你当前的测试逻辑是每轮循环先后调用Peek和Read，两个方法都做了重复的pos == length判断，还各自触发一次字符串索引访问，相当于把边界检查的差异放大了一倍。如果你把循环逻辑改成直接调用Read直到返回-1，省略Peek的调用，会发现两者的性能差距会大幅缩小。

补充说明：如果你将测试环境切换到.NET 6及以上版本，两者的性能差距会明显缩小，因为新版.NET的JIT已经支持对普通用户代码做边界检查消除优化，只要你的手动判断逻辑符合JIT的优化规则。

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