一尘不染

“ as”和可为空的类型带来的性能惊喜

c#

我只是修改了Depth中有关可空类型的C#第4章,并添加了有关使用“ as”运算符的部分,该部分允许您编写:

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

我认为这真的很整洁,并且可以使用“ is”和强制类型转换来提高C#1等效项的性能-毕竟,这种方式我们只需要进行一次动态类型检查,然后进行简单的值检查。

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

isinst可空类型的.NET实现真的很慢吗?是unbox.any导致问题的其他因素吗?还有其他解释吗?目前,感觉就像我将不得不警告不要在性能敏感的情况下使用此功能…

结果:

演员:10000000:121
如: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);
    }
}

阅读 237

收藏
2020-05-19

共1个答案

一尘不染

显然,JIT编译器可以为第一种情况生成的机器代码效率更高。确实有帮助的一条规则是,只能将对象取消装箱到与装箱值具有相同类型的变量。这使JIT编译器可以生成非常有效的代码,而无需考虑值转换。


运营商的测试很容易,只要检查对象是不是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可能会在这里引起麻烦。

2020-05-19