C#编译器或JIT可以优化lambda表达式中的方法调用吗?

时间:2016-04-06 23:50:03

标签: c# optimization lambda jit constant-expression

我在另一个StackOverflow问题上开始(in comments)的讨论后开始这个问题,我很想知道答案。考虑以下表达式:

var objects = RequestObjects.Where(r => r.RequestDate > ListOfDates.Max());

在这种情况下,将ListOfDates.Max()的评估移出Where子句会有什么(性能)优势,还是1.编译器或2. JIT优化它?

我相信C#只会在编译时进行常量折叠,并且可以说ListOfDates.Max()在编译时是不可知的,除非ListOfDates本身在某种程度上是常量。

也许有另一个编译器(或JIT)优化确保只评估一次?

1 个答案:

答案 0 :(得分:15)

嗯,这是一个复杂的答案。

这里涉及两件事。 (1)编译器和(2)JIT。

编译器

简单地说,编译器只是将您的C#代码转换为IL代码。对于大多数情况来说,它是一个非常简单的翻译,.NET的核心思想之一是每个函数都被编译为IL代码的自治块。

所以,不要期望C#太多 - > IL编译器。

JIT

那......有点复杂。

JIT编译器基本上将您的IL代码转换为汇编程序。 JIT编译器还包含基于SSA的优化器。但是,这是一个时间限制,因为我们不想在代码开始运行之前等待太久。基本上这意味着JIT编译器不会做所有超级酷的东西,这会使你的代码变得非常快,只是因为这会花费太多时间。

我们当然可以对它进行测试:)确保VS在您运行时进行优化(选项 - >调试器 - >取消选中抑制[...]和我的代码),在x64发布模式下编译,设置一个断点,看看切换到汇编视图时会发生什么。

但是,嘿,只有理论才有趣;让我们对它进行测试。 :)

static bool Foo(Func<int, int, int> foo, int a, int b)
{
    return foo(a, b) > 0;  // put breakpoint on this line.
}

public static void Test()
{
    int n = 2;
    int m = 2;
    if (Foo((a, b) => a + b, n, m)) 
    {
        Console.WriteLine("yeah");
    }
}

首先要注意的是断点被击中了。这已经说明了方法的内联;如果是的话,你根本就不会碰到断点。

接下来,如果您观看汇编程序输出,您会注意到&#39;来电&#39;使用地址的说明。这是你的功能。仔细观察后,您会注意到它正在给代表打电话。

现在,基本上这意味着调用没有内联,因此未针对本地(方法)上下文进行优化。换句话说,不使用委托并在您的方法中放置东西可能比使用委托更快。

另一方面,呼叫 非常有效。基本上,函数指针只是传递和调用。没有vtable查找,只是一个简单的调用。这意味着它可能胜过调用成员(例如IL callvirt)。静态调用(IL call)应该更快,因为这些是可预测的编译时间。再一次,让我们来测试一下吗?

public static void Test()
{
    ISummer summer = new Summer();
    Stopwatch sw = Stopwatch.StartNew();
    int n = 0;
    for (int i = 0; i < 1000000000; ++i)
    {
        n = summer.Sum(n, i);
    }
    Console.WriteLine("Vtable call took {0} ms, result = {1}", sw.ElapsedMilliseconds, n);

    Summer summer2 = new Summer();
    sw = Stopwatch.StartNew();
    n = 0;
    for (int i = 0; i < 1000000000; ++i)
    {
        n = summer.Sum(n, i);
    }
    Console.WriteLine("Non-vtable call took {0} ms, result = {1}", sw.ElapsedMilliseconds, n);

    Func<int, int, int> sumdel = (a, b) => a + b;
    sw = Stopwatch.StartNew();
    n = 0;
    for (int i = 0; i < 1000000000; ++i)
    {
        n = sumdel(n, i);
    }
    Console.WriteLine("Delegate call took {0} ms, result = {1}", sw.ElapsedMilliseconds, n);

    sw = Stopwatch.StartNew();
    n = 0;
    for (int i = 0; i < 1000000000; ++i)
    {
        n = Sum(n, i);
    }
    Console.WriteLine("Static call took {0} ms, result = {1}", sw.ElapsedMilliseconds, n);
}

结果:

Vtable call took 2714 ms, result = -1243309312
Non-vtable call took 2558 ms, result = -1243309312
Delegate call took 1904 ms, result = -1243309312
Static call took 324 ms, result = -1243309312

这里有趣的事实上是最新的测试结果。请记住,静态调用(IL call)是完全确定的。这意味着优化编译器是一件相对简单的事情。如果检查汇编程序输出,则会发现对Sum的调用实际上是内联的。这是有道理的。实际上,如果你要测试它,只需将代码放入方法中就像静态调用一样快。

有关Equals的小评论

如果你测量哈希表的性能,我的解释似乎有点可疑。看起来如果IEquatable<T>使事情变得更快。

嗯,这确实是真的。 :-)哈希容器使用IEquatable<T>来调用Equals。现在,众所周知,对象都实现了Equals(object o)。因此,容器可以调用Equals(object)Equals(T)。呼叫本身的性能是一样的。

但是,如果您还实现IEquatable<T>,则实现通常如下所示:

bool Equals(object o)
{
    var obj = o as MyType;
    return obj != null && this.Equals(obj);
}

此外,如果MyType是结构,则运行时还需要应用装箱和拆箱。如果它只是调用IEquatable<T>,则不需要这些步骤。因此,即使看起来较慢,这与呼叫本身无关。

您的问题

  

在这种情况下,将ListOfDates.Max()的评估移出Where子句会有什么(性能)优势,还是1.编译器或2. JIT优化它?

是的,会有优势。编译器/ JIT不会对它进行优化。

  

我相信C#只会在编译时进行常量折叠,并且可以说ListOfDates.Max()在编译时是不可知的,除非ListOfDates本身在某种程度上是常量。

实际上,如果您将静态调用更改为n = 2 + Sum(n, 2),您会注意到汇编程序输出将包含4。这证明了JIT优化器确实可以进行常量折叠。 (实际上,如果您了解SSA优化器的工作方式,那么很明显...... const折叠和简化被称为几次)。

函数指针本身未经优化。但它可能在未来。

  

也许有另一个编译器(或JIT)优化确保只评估一次?

对于另一个编译器&#39;,如果您愿意添加另一种语言&#39;,则可以使用C ++。在C ++中,这些类型的调用有时会被优化掉。

更有趣的是,Clang基于LLVM,并且还有一些用于LLVM的C#编译器。我相信Mono可以选择优化LLVM,CoreCLR正在研究LLILC。虽然我还没有对此进行测试,但LLVM绝对可以进行这些优化。