是旧版本的String.Equals的性能较差，因为没有首先检查null

本文关键字：因为 null 检查 版本 String Equals 性能 | 更新日期: 2023-09-27 18:25:35

我在我正在处理的代码库中不断遇到这样的代码：

private bool Equals(string s1, string s2)
{
    if (s1 == null && s2 == null)
        return true;
    else if (s1 != null && s2 == null)
        return false;
    else if (s1 == null && s2 != null)
        return false;
    else
        return s1.CompareTo(s2) == 0;
}

当我当时问我的经理为什么我们这样做而不是只使用string.Equals(s1, s2)时，他说这是一个更快、性能更好的字符串比较版本，因为它首先进行null检查。

这是真的吗？是使用当前版本的.Net，还是使用旧版本？

代码库看起来是用.Net 1.1或2.0创建的，目前是3.5版本。我不断发现许多这样的微观优化，这些优化可能是.Net Framework早期版本的问题，也可能不是。

（关于s1.ComareTo(s2) == 0代码行，他声称同一个字符串有时会在内存中存在不止一次，并且可能会使用错误的版本来比较字符串……我最终让他接受了我对string.Equals(s1, s2)的使用，但这可能会告诉你代码有多旧，我的老板来自哪个时间段）

是旧版本的String.Equals的性能较差，因为没有首先检查null

快速检查当前.NET源代码中的String，可以发现肯定会检查null。EqualsHelper的代码也在同一类中。

EDIT初始答案具有字符串实例版本的源代码。这是静态版本。无论版本如何，在调用EqualsHelper之前都会检查null。

// Determines whether two Strings match.
[Pure]
public static bool Equals(String a, String b) {
    if ((Object)a==(Object)b) {
        return true;
    }
    if ((Object)a==null || (Object)b==null) {
        return false;
    }
    if (a.Length != b.Length)
        return false;
    return EqualsHelper(a, b);
}
相关文章：