VB.NET中Option Compare Text为何性能远低于Equals方法？

测试场景与现象 #

最近了解到Option Compare Text，于是编写了以下测试代码：

Dim sw As New Stopwatch()
Dim w As Boolean = False
sw.Reset()
sw.Start()
Dim A As String = "hello, world"
For o As Integer = 1 To 1000000
    If A = "HELLO, world" Then
        w = True
    End If
Next o
sw.Stop()
Console.WriteLine(sw.Elapsed.TotalMilliseconds & vbTab & w.ToString)

测试结果：

• 未开启Option Compare Text时，运行耗时约6毫秒
• 开启该选项后，耗时约450毫秒
• 改用String.Equals指定忽略大小写的写法：

If A.Equals("HELLO, world", StringComparison.CurrentCultureIgnoreCase) Then

仅耗时135毫秒

问题：为何启用Option Compare Text后使用=进行字符串比较，性能远低于Equals方法？

核心原因 #

• Option Compare Text的底层兼容开销：启用该选项后，VB.NET的=字符串比较会调用Microsoft.VisualBasic.CompilerServices.StringType.StrCmpText方法。这个方法为了兼容VB旧版本的行为，额外增加了空字符串判断、Nothing值处理等逻辑，并且在调用CultureInfo.CurrentCulture.CompareInfo.Compare时还会做一层包装，这些额外步骤会带来明显的性能损耗。
• String.Equals的针对性优化：String.Equals(String, String, StringComparison)是直接调用.NET底层的CompareInfo比较逻辑，没有VB兼容层的额外开销。它针对指定的比较规则（比如CurrentCultureIgnoreCase）做了直接的优化路径，不需要处理VB特定的边缘情况，因此性能更高效。
• 默认序数比较的高效性：未开启Option Compare Text时，=使用的是序数比较（Ordinal），这种方式直接基于字符的Unicode码点对比，完全不考虑文化差异，是最快的字符串比较方式，所以耗时极低。

补充说明：百万次循环会把微小的单步开销放大，这也是三种场景耗时差距明显的原因——StrCmpText的兼容逻辑每次比较都要多走几个分支，累加起来就造成了和String.Equals的数百毫秒差距。

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