C#中如何避免指针字段属性调用开销？能否强制编译器内联？

在C#的unsafe代码场景中，通过封装类的属性访问结构体指针字段时，相比直接访问指针字段会产生方法调用开销。是否可以避免该属性方法调用的开销（比如强制编译器内联？我知道这更类似别名，但C#中没有此机制）？

相关代码示例 #

unsafe public static class Results
{
    public static void Test()
    {
        var cstruct = new CStruct();
        var obj     = new WrapperForCStruct(&cstruct);
        var x       = obj.Field;
        var y       = obj.ptr->field;
    }
}

public struct CStruct
{
    public int field;
}

unsafe public sealed class WrapperForCStruct(CStruct* pointer)
{
    public CStruct* ptr = pointer;

    public int Field => ptr->field;
}

IL代码对比 #

var x = obj.Field;
IL_0010: dup
IL_0011: callvirt instance int32 WrapperForCStruct::get_Field()
IL_0016: pop

var y = obj.ptr->field;
IL_0017: ldfld valuetype CStruct* WrapperForCStruct::ptr
IL_001c: ldobj CStruct
IL_0021: pop

Release模式优化后的反汇编对比 #

var x = obj.Field;
00007FFDB5C43E96  mov         rcx,qword ptr [rbp-10h]  
00007FFDB5C43E9A  cmp         dword ptr [rcx],ecx  
00007FFDB5C43E9C  call        qword ptr [CLRStub[MethodDescPrestub]@00007FFDB5E4D5F0 (07FFDB5E4D5F0h)]  
00007FFDB5C43EA2  mov         dword ptr [rbp-14h],eax  
00007FFDB5C43EA5  nop  

var y = obj.ptr->field;
00007FFDB4223E97  mov         rcx,qword ptr [rbp-10h]  
00007FFDB4223E9B  mov         rcx,qword ptr [rcx+8]  
00007FFDB4223E9F  cmp         byte ptr [rcx],cl  

可以通过以下几种方式规避属性的方法调用开销：

1. 添加AggressiveInlining特性
   给属性的getter方法标注[MethodImpl(MethodImplOptions.AggressiveInlining)]，明确告知编译器优先内联该方法。修改后的属性定义如下：

   [MethodImpl(MethodImplOptions.AggressiveInlining)]
   public int Field => ptr->field;
   

   对于这种简单的getter逻辑，Release模式下编译器几乎会100%完成内联优化，最终生成的汇编代码和直接访问指针字段的版本一致，消除方法调用的开销。

2. 使用ref readonly返回（C# 7.2及以上）
   如果需要的是字段的引用而非值拷贝，可以用ref readonly返回结构体字段的引用，既保留封装性，又能避免额外开销：

   [MethodImpl(MethodImplOptions.AggressiveInlining)]
   public ref readonly int Field => ref ptr->field;
   

   访问时直接使用var x = obj.Field;即可，性能表现和直接操作指针字段无差别。

3. 直接暴露指针字段（极端场景可选）
   完全放弃封装性，直接通过obj.ptr->field访问是开销最小的方式，但这会让外部代码直接操作内部指针，大幅增加代码维护风险，仅建议在性能优先级远高于代码可维护性的场景下使用。

需要注意的是，即使添加了AggressiveInlining，编译器仍会根据方法复杂度等情况决定是否内联，但针对示例中的简单逻辑，内联优化是必然发生的。

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