C＃编译器是否足够聪明以优化此代码？

Question

请忽略此问题中的代码可读性。

在性能方面，应将以下代码编写为：

int maxResults = criteria.MaxResults;

if (maxResults > 0)
{
    while (accounts.Count > maxResults)
        accounts.RemoveAt(maxResults);
}

或像这样：

if (criteria.MaxResults > 0)
{
    while (accounts.Count > criteria.MaxResults)
        accounts.RemoveAt(criteria.MaxResults);
}

？

编辑： criteria是一个class ， MaxResults是一个简单的整数属性（即public int MaxResults { get { return _maxResults; } } 。

C＃编译器是否将MaxResults视为黑盒并每次对其进行评估？ 还是足够聪明地弄清楚我有3个调用相同属性的调用，而两次调用之间没有对该属性的修改？ 如果MaxResults是一个字段怎么办？

优化的法则之一是预先计算，因此我本能地像第一个清单那样编写此代码，但是我很好奇这种事情是否是自动为我完成的（再次，请忽略代码的可读性）。

（注意：我对听到“微优化”的论点不感兴趣，该论点在我所发布的特定案例中可能是有效的。我只想了解正在发生或未发生的事情背后的理论。）

Answer 1

首先，实际回答性能问题的唯一方法是实际尝试两种方法并在实际条件下测试结果。

也就是说，其他回答说“编译器”不执行此优化，因为该属性可能会产生副作用，这是对还是错。 该问题的问题（除了根本的问题，即如果不实际尝试并测量结果就无法回答），实际上“编译器”是两个编译器：编译为MSIL的C＃编译器和JIT编译器，将IL编译为机器代码。

C＃编译器从不进行这种优化。 如前所述，这样做将要求编译器查看正在调用的代码，并验证其计算的结果在被调用者代码的生存期内未发生变化。 C＃编译器不这样做。

JIT编译器可能会这样做。 没有理由不能这样做。 它拥有所有代码。 内联属性获取器是完全免费的，如果抖动确定内联属性获取器返回的值可以缓存在寄存器中并可以重新使用，则可以这样做。 （如果您不希望这样做，因为可以在另一个线程上修改该值，则说明您已经有一个竞争条件错误；请在担心性能之前修复该错误。）

抖动是否确实内联了属性获取并随后注册了值，我不知道。 我对抖动几乎一无所知。 但是，如果认为合适，则可以这样做。 如果您对是否这样做感到好奇，则可以（1）询问编写抖动的团队中的某个人，或者（2）在调试器中检查抖动的代码。

最后，让我借此机会指出，一次计算结果，存储结果并重新使用它并不总是一种优化 。 这是一个令人惊讶的复杂问题。 有许多要优化的东西：

• 执行时间处理时间

• 可执行代码的大小-这对可执行时间有重大影响，因为大代码的加载时间更长，工作集大小增加，对处理器缓存，RAM和页面文件施加压力。 在启动时间和缓存局部性等重要指标上，小而慢的代码从长远来看通常比大而快速的代码更快 。

• 寄存器分配-这对执行时间也有重要影响，特别是在x86之类的架构中，可用寄存器数量很少。 为快速重用而注册一个值可能意味着更少的寄存器可用于其他需要优化的操作。 也许优化这些操作将是一个净赢。

• 等等。 它很快就会变得复杂。

简而言之，您可能无法知道编写代码来缓存结果而不是重新计算结果实际上是（1）更快，还是（2）性能更好。 更好的性能并不总是意味着更快地执行特定例程。 更好的性能在于确定哪些资源对用户很重要-执行时间，内存，工作集，启动时间等-并对这些内容进行优化。 没有（1）与客户交谈以找出他们关心的问题，以及（2）实际进行测量以查看您的更改是否在预期的方向上产生了可测量的效果，您就无法做到这一点。

Answer 2

如果MaxResults是一个属性，则为no，它将不会对其进行优化，因为getter可能具有复杂的逻辑，例如：

private int _maxResults;
public int MaxReuslts {
  get { return _maxResults++; }
  set { _maxResults = value; }
}

看看如果内联代码会改变行为？

如果没有逻辑...您编写的任何一种方法都很好，那将是非常微小的差异，而且关于您（或您的团队）的可读性...都是您的选择。

Answer 3

仅保证您的两个代码示例在单线程环境中具有相同的结果，而.Net并非如此，并且MaxResults是一个字段（而不是属性）。 除非您使用同步功能，否则编译器无法假定该criteria.MaxResults .MaxResults在循环过程中不会更改。 如果它是一个属性，则不能假设使用该属性没有副作用。

埃里克·利珀特（Eric Lippert）相当正确地指出，它很大程度上取决于您所说的“编译器”的含义。 C＃-> IL编译器？ 还是IL->机器代码（JIT）编译器？ 他正确地指出，JIT可能能够优化属性获取器，因为它具有所有信息（而C＃-> IL编译器则不一定）。 它不会改变具有多个线程的情况，但这仍然是一个好主意。

Answer 4

每次都会调用并评估它。 编译器无法确定方法（或getter）是否是确定性的和纯净的（无副作用）。

请注意，JIT编译器可以内联该属性的实际评估，从而使其与简单字段一样有效。

优良作法是使属性评估成为廉价操作。 如果在getter中进行大量计算，请考虑手动缓存结果，或将其更改为方法。

Answer 5

为什么不测试呢？

只需设置2个控制台应用程序，使其看起来达到1000万次并比较结果...请记住将它们作为已正确安装的正确发布的应用程序运行，否则您将无法保证自己不仅在运行msil。

确实，您可能会得到大约5个答案，说“您不应该担心优化”。 他们显然并没有编写在可读之前需要尽可能快的例程（例如游戏）。

如果这段代码是执行数十亿次循环的一部分，那么这种优化可能是值得的。 例如，最大结果可能是覆盖的方法，因此您可能需要讨论虚拟方法调用。

真正回答这些问题的唯一方法就是弄清楚这是一段将从优化中受益的代码。 然后，您需要了解增加执行时间的各种事情。 真的，我们仅仅是凡人不能先验地做到这一点，因此必须简单地尝试2-3个不同版本的代码，然后对其进行测试。

Answer 6

如果criteria是类类型，我怀疑它会被优化，因为与此同时另一个线程总是可以更改该值。 对于struct我不确定，但是我的直觉是不会对其进行优化，但是我认为无论如何在性能上都不会有太大的不同。