c# - "as"和可空类型的性能惊喜

Question

我只是修改了 C# 深入探讨可空类型的第 4 章，并添加了有关使用“as”运算符的部分，它允许您编写:

object o = ...;
int? x = o as int?;
if (x.HasValue)
{
    ... // Use x.Value in here
}

我认为这真的很巧妙，并且它可以提高性能超过 C# 1 等效项，使用“is”后跟强制转换 - 毕竟，这样我们只需要请求动态类型检查一次，然后简单的值检查。

然而，情况似乎并非如此。我在下面包含了一个示例测试应用程序，它基本上对对象数组中的所有整数求和 - 但该数组包含大量空引用和字符串引用以及装箱整数。该基准衡量您必须在 C# 1 中使用的代码，使用“as”运算符的代码，以及仅用于启动 LINQ 解决方案的代码。令我惊讶的是，在这种情况下，C# 1 代码快了 20 倍 - 甚至 LINQ 代码(考虑到涉及的迭代器，我预计它会更慢)也击败了“as”代码。

可空类型的 isinst 的 .NET 实现真的很慢吗？是不是额外的 unbox.any 导致了这个问题？对此还有其他解释吗？目前感觉我将不得不在对性能敏感的情况下使用它的警告......

结果:

Cast: 10000000 : 121
As: 10000000 : 2211
LINQ: 10000000 : 2143

代码:

using System;
using System.Diagnostics;
using System.Linq;

class Test
{
    const int Size = 30000000;

    static void Main()
    {
        object[] values = new object[Size];
        for (int i = 0; i < Size - 2; i += 3)
        {
            values[i] = null;
            values[i+1] = "";
            values[i+2] = 1;
        }

        FindSumWithCast(values);
        FindSumWithAs(values);
        FindSumWithLinq(values);
    }

    static void FindSumWithCast(object[] values)
    {
        Stopwatch sw = Stopwatch.StartNew();
        int sum = 0;
        foreach (object o in values)
        {
            if (o is int)
            {
                int x = (int) o;
                sum += x;
            }
        }
        sw.Stop();
        Console.WriteLine("Cast: {0} : {1}", sum, 
                          (long) sw.ElapsedMilliseconds);
    }

    static void FindSumWithAs(object[] values)
    {
        Stopwatch sw = Stopwatch.StartNew();
        int sum = 0;
        foreach (object o in values)
        {
            int? x = o as int?;
            if (x.HasValue)
            {
                sum += x.Value;
            }
        }
        sw.Stop();
        Console.WriteLine("As: {0} : {1}", sum, 
                          (long) sw.ElapsedMilliseconds);
    }

    static void FindSumWithLinq(object[] values)
    {
        Stopwatch sw = Stopwatch.StartNew();
        int sum = values.OfType<int>().Sum();
        sw.Stop();
        Console.WriteLine("LINQ: {0} : {1}", sum, 
                          (long) sw.ElapsedMilliseconds);
    }
}

Answer 1

显然，JIT 编译器可以为第一种情况生成的机器码效率更高。一个真正有用的规则是一个对象只能被拆箱到一个与装箱值具有相同类型的变量。这允许 JIT 编译器生成非常高效的代码，无需考虑值转换。

is 运算符测试很简单，只需检查对象是否不为 null 以及是否属于预期类型，只需要几条机器代码指令。转换也很容易，JIT 编译器知道对象中值位的位置并直接使用它们。没有复制或转换发生，所有机器代码都是内联的并且只需要大约十二条指令。在装箱很普遍的 .NET 1.0 中，这需要非常高效。

转换为 int？需要更多的工作。装箱整数的值表示与 Nullable<int> 的内存布局不兼容.需要进行转换，并且由于可能的盒装枚举类型，代码很棘手。 JIT 编译器生成对名为 JIT_Unbox_Nullable 的 CLR 辅助函数的调用以完成工作。这是任何值类型的通用函数，其中有很多代码可以检查类型。并且值被复制。很难估计成本，因为此代码被锁定在 mscorwks.dll 中，但可能有数百条机器代码指令。

Linq OfType() 扩展方法还使用 is 运算符和强制转换。然而，这是对通用类型的强制转换。 JIT 编译器生成对辅助函数 JIT_Unbox() 的调用，该函数可以执行转换为任意值类型。我没有很好的解释为什么它像转换为 Nullable<int> 一样慢，因为应该需要更少的工作。我怀疑 ngen.exe 可能会在这里造成麻烦。