c# - 为什么不尽可能使用 "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

在某些情况下这是不可能的，例如当您需要修改参数或使用不允许 in 的异步或迭代器方法时。但问题是，在 99% 的情况下，参数只是读取，那么为什么不指定in？

当未指定in时，传递的参数将复制到局部变量。这种复制可能会花费一些时间，这对于紧密循环中的大型结构体来说是显而易见的，如 Microsoft says here 。

使用in，引用被传递，因此不会发生复制。也许在大多数情况下，不复制节省的时间可以忽略不计，但我想知道除了标准的“它使代码困惑”或“这是一个你不应该担心的微优化”之外，是否还有其他原因。

据我所知，这种绕过结构复制的“微优化”正是引入 in 的原因。是否还有其他原因表明，对于性能关键型代码来说，将其扔到各处是一种不好的做法？

Answer 1

它也有利于紧密耦合。例如，MSDN 中的以下方法 ( https://learn.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

这是一个有趣的优化链接(我复制了他们的结果)其中讨论了 readonly struct、readonly ref 和 in: https://faithlife.codes/blog/2017/12/in-will-make-your-code-slower/

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

一些进一步的阅读(来源:Jon Skeet):

微优化:只读字段令人惊讶的低效

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