为什么不尽可能使用“in”作为方法参数？

Question

在 C# 中，我们可以指定结构方法参数，以便将它们作为只读引用传递：inpublic int TimesTwo(in int number){    return number * 2;}这与 使用 几乎相同，但不允许修改参数：refpublic int TimesTwo(in int number){    number *= 2; // Compiler error    return number;}此外，它不需要在调用时指定关键字，就像：refvar x = 1;var y = TimesTwo(x);var z = TimesTwo(in x);// y and z are both 2在某些情况下，这是不可能的，例如当您需要修改参数或使用不允许的异步或迭代器方法时。但问题是，在99%的情况下，参数只是被读取，那么为什么不指定in呢？in如果未指定，则传递的参数将复制到局部变量。这种复制可能需要一些时间，对于紧密循环中的大型结构来说，这可能是明显的，正如微软在这里所说的那样。in使用 ，则传递引用，因此不会发生复制。也许在大多数情况下，不复制所节省的时间可以忽略不计，但我想知道除了标准的“它使代码混乱”或“这是一个你不应该担心的微优化”之外，是否有任何原因。in据我所知，这种绕过结构复制的“微优化”正是引入的原因。还有其他原因可以解释为什么将其放在任何地方用于性能关键代码都是不好的做法吗？in

Answer 1

它也有利于紧密耦合。例如，MSDN 中的以下方法 （https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/in-parameter-modifier）：

static void Method(in int argument)

{

    // implementation removed

}

Method(5); // ok

Method(5L); // CS1503: no implicit conversion from long to int

这是一个有趣的优化链接（我复制了他们的结果），它讨论了，和：https://faithlife.codes/blog/2017/12/in-will-make-your-code-slower/readonly structreadonly refin

Method                  Mean

PointByValue            25.09 ns

PointByRef              21.77 ns

PointByIn               34.59 ns  // our guy

ReadOnlyPointByValue    25.29 ns

ReadOnlyPointByRef      21.78 ns

ReadOnlyPointByIn       21.79 ns

Image caption 一些进一步的阅读（图片来源：Jon Skeet）：

微观优化：只读场的惊人低效率

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