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

Question

在 C# 中，我们可以指定结构方法参数，以便将它们作为只读引用传递：in

public int TimesTwo(in int number)

{

    return number * 2;

}

这与 使用 几乎相同，但不允许修改参数：ref

public int TimesTwo(in int number)

{

    number *= 2; // Compiler error

    return number;

}

此外，它不需要在调用时指定关键字，就像：ref

var 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); // okMethod(5L); // CS1503: no implicit conversion from long to int这是一个有趣的优化链接（我复制了他们的结果），它讨论了，和：https://faithlife.codes/blog/2017/12/in-will-make-your-code-slower/readonly structreadonly refinMethod                  MeanPointByValue            25.09 nsPointByRef              21.77 nsPointByIn               34.59 ns  // our guyReadOnlyPointByValue    25.29 nsReadOnlyPointByRef      21.78 nsReadOnlyPointByIn       21.79 nsImage caption 一些进一步的阅读（图片来源：Jon Skeet）：微观优化：只读场的惊人低效率https://codeblog.jonskeet.uk/2014/07/16/micro-optimization-the-surprising-inefficiency-of-readonly-fields/