令人惊讶的是，只读实际上会导致代码变慢，正如Jon Skeet在测试他的Noda Time库时发现的那样。在本例中，一个在20秒内运行的测试在删除readonly后只花了4秒。

https://codeblog.jonskeet.uk/2014/07/16/micro-optimization-the-surprising-inefficiency-of-readonly-fields/

WPF可以带来性能上的好处，因为它不需要昂贵的DependencyProperties。这对于集合尤其有用

我认为使用只读字段不会带来任何性能上的提升。这只是一个检查，以确保一旦对象完全构造，该字段不能指向一个新值。

然而，“readonly”与其他类型的只读语义非常不同，因为它是由CLR在运行时强制执行的。readonly关键字编译为.initonly，这是CLR可以验证的。

这个关键字的真正优点是生成不可变的数据结构。根据定义，不可变数据结构一旦构造就不能更改。这使得在运行时推断结构的行为变得非常容易。例如，将不可变结构传递给代码的另一个随机部分是没有危险的。他们永远不能改变它，所以你可以根据这个结构可靠地编程。

Robert Pickering写了一篇关于不变性的好处的博客文章。这篇文章可以在这里或archive.org上找到。

如果你有一个预先定义或预先计算的值，需要在整个程序中保持不变，那么你应该使用constant，但如果你有一个值需要在运行时提供，但一旦分配，应该在整个程序中保持不变，你应该使用readonly。例如，如果你必须分配程序的开始时间，或者你必须在对象初始化时存储用户提供的值，并且你必须限制它进一步更改，你应该使用readonly。

请记住，readonly只应用于值本身，所以如果您使用引用类型，readonly只保护引用不被更改。实例的状态不受只读保护。

有一种可能的情况是，编译器可以基于readonly关键字的存在进行性能优化。

这仅适用于只读字段也标记为静态的情况。在这种情况下，JIT编译器可以假设这个静态字段永远不会改变。JIT编译器在编译类的方法时可以考虑到这一点。

一个典型的例子:你的类可以有一个静态只读的IsDebugLoggingEnabled字段，在构造函数中初始化(例如基于配置文件)。一旦实际的方法被jit编译，当调试日志未启用时，编译器可能会省略代码的整个部分。

我没有检查这个优化是否在当前版本的JIT编译器中实际实现，所以这只是推测。