.NET 8中operator ++为何比等价实例方法快两倍以上？

我在.NET 8环境下用BenchmarkDotNet对以下代码做了基准测试：

using System.Runtime.InteropServices;
using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;

[StructLayout(LayoutKind.Explicit)]
public readonly struct Counter
{
    [FieldOffset(0)] public readonly int Value;
    [FieldOffset(1)] public readonly byte MidByte;

    public Counter(int value)
        : this()
    {
        this.Value = value;
    }

    public Counter Increment(int count) // 0 <= count <= 32
    {
        int value = this.Value + count;
        int lowByte = (byte)value;
        if (lowByte > 32)
            value = value - 32 + (this.MidByte < 16 ? 0x100 : 0xF100);
        return new Counter(value);
    }

    public static Counter operator ++(Counter counter) => counter.Increment(1);
}

public class Benchmarks
{
    [Benchmark]
    public Counter Benchmark1()
    {
        Counter c = new(0x10101);
        for (int i = 0; i < 10000; ++i) {
            c = c.Increment(1);
        }
        return c;
    }

    [Benchmark]
    public Counter Benchmark2()
    {
        Counter c = new(0x10101);
        for (int i = 0; i < 10000; ++i) {
            ++c;
        }
        return c;
    }
}

Benchmark1和Benchmark2的唯一区别是：Benchmark2调用operator ++（内部直接调用Increment(1)），而Benchmark1直接调用Increment(1)。我原本以为JIT会内联operator ++，两者性能应该一致，但结果却出乎意料——++c的性能远超c = c.Increment(1)：

BenchmarkDotNet v0.13.8, Windows 10 (10.0.19045.4651/22H2/2022Update)
11th Gen Intel Core i7-11800H 2.30GHz, 1 CPU, 16 logical and 8 physical cores
.NET SDK 8.0.303
 [Host] : .NET 8.0.7 (8.0.724.31311), X64 RyuJIT AVX2
 DefaultJob : .NET 8.0.7 (8.0.724.31311), X64 RyuJIT AVX2

方法	平均值	误差	标准差	代码大小
Benchmark1	18.376 us	0.1999 us	0.1870 us	68 B
Benchmark2	6.564 us	0.0436 us	0.0408 us	81 B

为什么明明operator ++只是调用Increment(1)，++c却比直接调用快这么多？

更新1：有人质疑++c是不是没更新c而是直接丢弃结果。我已经验证过，Benchmark1和Benchmark2返回的Counter值完全相同（都是0x00140911），说明两个测试都执行了10000次计算。

更新2：如果把Counter.Increment中对this.MidByte的引用替换成等价的(byte)(value >> 8)，Benchmark1和Benchmark2的性能差异就消失了：

原因分析 #

这个差异的核心是RyuJIT对显式布局结构体的字段访问优化逻辑不同，尤其是处理FieldOffset重叠字段时：

1. 直接调用Increment时的额外开销：
   当直接调用c.Increment(1)，方法内部访问this.MidByte时，由于MidByte和Value是重叠布局（Value占4字节，MidByte在偏移1处），JIT无法确定this.Value的修改是否会影响this.MidByte——哪怕this是只读结构体，JIT也没有足够的分析能力确认这一点，导致它每次都要从内存重新读取MidByte的值，而非复用寄存器里已有的Value计算结果。

2. 调用operator ++时的优化：
   operator ++是静态方法，接收的是Counter结构体的副本。JIT在处理静态运算符方法时，对结构体字段的访问分析更激进：它能识别到MidByte可以直接从传入的counter.Value的第二个字节推导得出（因为布局是显式定义的），因此会直接复用寄存器里的Value值计算MidByte，避免了额外的内存读取操作。

3. 更新2的验证逻辑：
   当把this.MidByte替换成(byte)(value >> 8)时，相当于手动帮JIT完成了字段推导——不管是直接调用还是通过运算符调用，JIT都能直接用寄存器里的value计算出需要的字节，不需要再去内存读取，因此两者性能完全一致。

简单来说：直接调用实例方法时，JIT对重叠字段的访问优化不足；而静态运算符方法的参数传递方式让JIT能更高效地优化字段访问，避免了不必要的内存IO。

内容的提问来源于stack exchange，提问作者Michael Liu