C# 直接返回值与创建临时变量之间的性能差异

与直接返回分配给该变量的值相比，在函数中创建临时变量是否有性能影响或内存消耗差异

例如，以下哪些函数（GetValue）在性能和节省内存方面更好，或者两者完全相同：

案例1：

  private string GetValue()
  {
     return this.GetResult();
  }

  private string GetResult()
  {
     // Code here that return a big string...
  }

案例2：

  private string GetValue()
  {
     string result = this.GetResult();

     return result;
  }

  private string GetResult()
  {
     // Code here that return a big string...
  }

---

谢谢。

在这些基本情况下，可读性总是胜过性能差异。我认为这是一种微不足道的优化充其量，这很大程度上是浪费时间。你在这上面省下的钱将被一个不确定的GC运行消耗掉

大多数情况下，如果允许编译器对结果代码进行优化，则结果代码不会有任何差异。在本例中，生成的IL似乎有一些额外的操作码用于引用堆栈上的字符串，但JIT随后会如何处理这一点，这是任何人的猜测

---

在返回之前，我有时会对临时变量进行检查，但我从不担心对性能的影响。最重要的是，我从未见过这样一种情况，即需要这种改进来解决性能问题。

如果可执行代码实际使用了局部变量，而不是将其优化掉，那么差异仍然很小

局部变量只使用存储引用所需的堆栈空间，分配空间根本不需要时间，因为堆栈帧始终是分配的

---

在局部变量之间创建额外副本的时间很难测量。如果你在一个紧循环中调用该方法数百万次，那么它只会起到作用，与分配字符串所需的时间相比，它仍然只是执行时间的一小部分。

局部变量始终是优化的

在返回语句之前使用局部变量不会影响性能

查看两个类的编译输出

我更喜欢总是使用局部变量，因为它可以加快调试速度。

---

据统计，开发人员75%的时间都花在调试上。

优化后，代码很可能是相同的。这是留给编译器去优化的事情。一般来说，如果局部变量能使代码更具可读性，那么可以放心地生成局部变量。编译器将优化掉您认为可能会导致的任何感知到的低效。如果JIT不优化它，性能差异将非常小，我认为根本不值得考虑。正如其他人所提到的，编译器优化可能会消除这两种方法之间的任何差异。无论如何，尽管如此，我很有信心，通过从一种方法更改为另一种方法，您永远不会遇到任何可以解决的性能问题。我发现，自由使用局部变量使调试器中的变量监视窗口更加有用。对我来说，这胜过了任何效率差异。只需补充一点，LINQPad报告的额外操作代码只是额外的

ldloc

，然后

stloc

。这只会出现在我假设的调试版本中。@ChrisSinclair不，这是一个以x86为目标的版本，并且启用了优化功能。@ChrisSinclair不知道，我使用的是ILSpy。当然，在发布模式下，它的IL没有我的调试版本那么详细。如果你愿意，我可以把它寄出去？不，没关系。我知道了解等价的IL以及编译器如何将其组合在一起通常是一件好事，但有时它就是这样！可能是背后的原因。如果你认为这对你的答案或塞缪尔有帮助，那就去吧。与LINQPad报道的内容没有太大区别；C代码非常简单。