在 C# 中的字段上使用 const 或 readonly 修饰符是否有任何性能优势？

Question

仅使用私有变量时，与常规可修改字段相比，使用 const 或 readonly 字段是否有任何性能优势。

例如：

public class FooBaar
{
     private string foo = "something";
     private const string baar = "something more"

     public void Baaz()
     {
         //access foo, access baar
     }
}

在上面的示例中，您可以看到有两个字段：foo 和 baar。两者在类之外都是无法访问的，所以为什么很多人更喜欢在这里使用 const，而不是仅仅使用 private。 const 是否提供任何性能优势？

---

这个问题之前被社区关闭了，因为人们将这个问题误解为“const 和 readonly 在性能方面有什么区别？” >，已在这里回答：const 和只读？。
但我真正的意思是，“与不使用其中任何一个相比，使用 const 或 readonly 是否能获得任何性能优势”。

Answer 1

const 将被编译器优化以内联到代码中，而 readonly 不能内联。但是，您不能创建所有类型的常量 - 所以在这里您必须将它们设置为只读。

因此，如果您的代码中需要一个常量值，您应该首先考虑使用 const（如果可能的话），如果没有，那么 readonly 可以让您获得安全性，但不会获得性能优势。

举个例子：

public class Example
{
    private const int foo = 5;
    private readonly Dictionary<int, string> bar = new Dictionary<int, string>();

    //.... missing stuff where bar is populated

    public void DoSomething()
    {
       Console.Writeline(bar[foo]);

       // when compiled the above line is replaced with Console.Writeline(bar[5]);
       // because at compile time the compiler can replace foo with 5
       // but it can't do anything inline with bar itself, as it is readonly
       // not a const, so cannot benefit from the optimization
    }
}

Answer 2

我也想知道这一点，并且我使用了一个工具来检查使用静态和只读修饰符所产生的 IL 输出。

检查这个示例：

public class C {

    const string test = "stuff";
    private static string test2 = "stuff2";

    public static void M() {
        System.Console.WriteLine(test);
        System.Console.WriteLine(test2);
    }
}

M() 的 IL 输出：

 IL_0000: nop
 IL_0001: ldstr "stuff"
 IL_0006: call void [System.Console]System.Console::WriteLine(string)
 IL_000b: nop
 IL_000c: ldsfld string C::test2
 IL_0011: call void [System.Console]System.Console::WriteLine(string)
 IL_0016: nop
 IL_0017: ret

它不太可能在当前硬件中产生任何性能差异，但似乎常量会将数据携带到 word 当CPU执行指令时，静态引用会携带一个内存指针，这将使CPU检索某个寄存器中的值/L1 缓存/等等。

完整输出：https://gist.github.com/VagnerGon/e8f48a652cc4f234c2ab060a5eeb7d2e

Answer 3

在遇到需要进行此类测量的关键代码之前，我不会太担心这些构造的性能。它们的存在是为了确保代码的正确性，而不是出于性能原因。