Question

假设我有以下程序：

static void SomeMethod(Func<int, int> otherMethod)
{
    otherMethod(1);
}

static int OtherMethod(int x)
{
    return x;
}

static void Main(string[] args)
{
    SomeMethod(OtherMethod);
    SomeMethod(x => OtherMethod(x));
    SomeMethod(x => OtherMethod(x));
}

我无法理解已编译的il代码（它使用了额外的代码）。这是简化版：

class C
{
    public static C c;
    public static Func<int, int> foo;
    public static Func<int, int> foo1;
    static C()
    {
        c = new C();
    }
    C(){}
    public int b(int x)
    {
        return OtherMethod(x);
    }
    public int b1(int x)
    {
        return OtherMethod(x);
    }
}

static void Main()
{
    SomeMethod(new Func<int, int>(OtherMethod));
    if (C.foo != null)
        SomeMethod(C.foo)
    else
    {
        C.foo = new Func<int, int>(c, C.b)
        SomeMethod(C.foo);
    }
    if (C.foo1 != null)
        SomeMethod(C.foo1)
    else
    {
        C.foo1 = new Func<int, int>(c, C.b1)
        SomeMethod(C.foo1);
    }
}

为什么编译器不创建静态相等方法b/b1？等于意味着它们具有相同的代码

Answer 1

你的问题是：为什么编译器没有意识到这两行

SomeMethod(x => OtherMethod(x));
SomeMethod(x => OtherMethod(x));

相同并将其写为

if ( delegate is not created ) 
  create the delegate and stash it away
SomeMethod( the delegate );
SomeMethod( the delegate );

？让我以几种方式回答这个问题。

首先，编译器允许进行优化吗？是。该规范要求C＃编译器允许使两个lambdas完全相同的东西进入一个委托。实际上你可以看到它已经部分地进行了这种优化：它创建每个代理一次并将其保存起来，以便以后在调用代码时不必再创建它再次。请注意，在仅调用一次代码的情况下，这会浪费内存。

第二，编译器是否需要进行缓存优化？不是。规范要求编译器仅允许进行优化，而不是必需。

编译器是否需要进行所需的优化？显然不是，因为它没有。它是允许的，也许是编译器的未来版本。编译器是开源的;如果您关心这种优化，请写下它并提交拉取请求。

第三，是否可能进行您想要的优化？是。编译器可以获取出现在同一方法中的所有lambda对，将它们编译为内部树格式，并进行树比较以查看它们是否具有相同的内容，然后为两者生成相同的静态后备字段。

所以现在我们遇到了一种情况：编译器允许进行特定的优化，而且它没有。你问过＆＃34;为什么不＆＃34;？这是一个很容易回答的问题：所有优化都没有实施，直到有人花费大量时间和精力：

仔细设计优化：在什么条件下触发优化并且不触发优化？优化应该有多普遍？你有没有建议他们发现类似的lambda尸体，但为什么要停在那里呢？您有两个相同的语句代码，那么为什么不一次为这些语句生成代码而不是两次？如果您有重复的语句组怎么办？这里有大量的设计工作。
特别是，设计的一个重要方面是：用户是否可以合理地进行优化＆＃34;手动＆＃34;同时仍保持代码可读。在这种情况下，是的，他们可以，轻松。只需将重复的lambda分配给变量，然后使用该变量。自动执行某项操作的用户可以轻松完成自己的优化，这种优化并不是非常有趣或引人注目的优化。
你的例子是微不足道的;现实世界的代码不是。您提出的设计与相同的嵌套 lambdas有什么关系？等等。
您的优化是否会导致调试器中代码的行为变得奇怪？＃34;？您可能已经注意到，在调试打开优化时编译的代码时，调试器似乎表现得很奇怪;这是因为生成的代码和原始代码之间不再有清晰的映射。您的优化会使情况变得更糟吗？用户可以接受吗？调试器是否需要了解优化？如果是这样，您将不得不更改调试器。在这种情况下，可能不是，但这些是你必须提出并回答的问题。
由专家审核设计;这会占用他们的时间，并可能导致设计的变化
估计优化的优缺点 - 优化通常会产生隐藏成本，比如我之前提到的内存泄漏。特别是，优化通常排除可能更好的其他优化。
估算此优化的全球总节省量。优化是否会影响实际代码？它是否会更改该代码的正确性？世界上任何地方都有任何生产代码会破坏这种优化并导致X公司的首席技术官要求微软的CTO要求修复吗？如果答案是肯定的，那么您可能想要不进行此优化。 C＃不是玩具。每天都有数以百万计的人依赖于正确的操作。
编译时进行优化的估算负担是什么？编译不必在击键之间发生，但它必须非常快。在编译器中的公共代码路径中引入超线性算法的任何东西都是不可接受的。您可以实现优化，使其在代码大小上呈线性吗？请注意，我之前绘制的算法 - 比较所有对 - 在代码大小上是超线性的。（练习：在所有lambda对上做树比较的最坏情况是什么？）
实际实施优化。我鼓励你这样做。
测试优化;它实际上产生了更好的代码吗？什么指标？不会导致任何指标变化的优化不是优化。
注册以永久修复优化中的错误。

您想要的优化根本不符合标准。没有人写这样的代码。如果他们这样做了，并且他们关心它复制了一个对象，他们可以轻松地自行修复它。因此，优化优化了不存在的代码，以便获得“胜利”。这是在程序将分配的数百万个对象中构建单个对象。不值得。

但是，如果您认为是这样，请继续执行并提交拉取请求。请务必提交我上面提到的调查结果，因为这些是实际工作的地方。实施通常是花在功能上的总工作量的最小部分;这就是为什么C＃是一种成功的语言。

由于缓存委托，c＃编译器的奇怪行为

1 个答案: