前言
书接上回，我们讨论了在.NET8中新增的UnsafeAccessor，并且通过UnsafeAccessor访问了私有成员，这极大的方便了我们代码的编写，当然也聊到了它当前存在的一些局限性，那么它的性能到底如何？我们今天就来实际测试一下。
测试代码
话不多说，直接上代码，本次测试代码如下：
using System.Linq.Expressions;
using System.Reflection;
using System.Reflection.Emit;
using System.Runtime.CompilerServices;
using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Columns;
using BenchmarkDotNet.Configs;
using BenchmarkDotNet.Order;
using BenchmarkDotNet.Reports;
using BenchmarkDotNet.Running;
using Perfolizer.Horology;
[MemoryDiagnoser]
[Orderer(SummaryOrderPolicy.FastestToSlowest)]
public class AccessBenchmarks
{
public static readonly A TestInstance = new();
public static readonly Action<A, int> SetDelegate;
public static readonly Func<A, int> GetDelegate;
public static readonly PropertyInfo ValueProperty;
public static readonly MethodInfo SetValueMethod;
public static readonly MethodInfo GetValueMethod;
public static readonly Func<A, int> GetValueExpressionFunc;
public static readonly Action<A, int> SetValueExpressionAction;
static AccessBenchmarks()
{
TestInstance = new();
ValueProperty = typeof(A).GetProperty("Value");
SetValueMethod = ValueProperty.GetSetMethod();
GetValueMethod = ValueProperty.GetGetMethod();
SetDelegate = CreateSetDelegate();
GetDelegate = CreateGetDelegate();
GetValueExpressionFunc = CreateGetValueExpressionFunc();
SetValueExpressionAction = CreateSetValueExpressionAction();
}
[UnsafeAccessor(UnsafeAccessorKind.Method, Name = "get_Value")]
static extern int GetValueUnsafe(A a);
[UnsafeAccessor(UnsafeAccessorKind.Method, Name = "set_Value")]
static extern void SetValueUnsafe(A a, int value);
[Benchmark]
public void UnsafeAccessor()
{
SetValueUnsafe(TestInstance, 10);
var value = GetValueUnsafe(TestInstance);
}
[Benchmark]
public void Reflection()
{
SetValueMethod.Invoke(TestInstance, new object[] { 10 });
var value = GetValueMethod.Invoke(TestInstance, new object[] { });
}
[Benchmark]
public void Emit()
{
SetDelegate(TestInstance, 10);
var value = GetDelegate(TestInstance);
}
[Benchmark]
public void ExpressionTrees()
{
SetValueExpressionAction(TestInstance, 10);
var value = GetValueExpressionFunc(TestInstance);
}
[Benchmark]
public void Direct()
{
TestInstance.Value = 10;
var value = TestInstance.Value;
}
private static Action<A, int> CreateSetDelegate()
{
var dynamicMethod = new DynamicMethod("SetValue", null, new[] { typeof(A), typeof(int) }, typeof(A));
var ilGenerator = dynamicMethod.GetILGenerator();
ilGenerator.Emit(OpCodes.Ldarg_0);
ilGenerator.Emit(OpCodes.Ldarg_1);
ilGenerator.EmitCall(OpCodes.Call, SetValueMethod, null);
ilGenerator.Emit(OpCodes.Ret);
return (Action<A, int>)dynamicMethod.CreateDelegate(typeof(Action<A, int>));
}
private static Func<A, int> CreateGetDelegate()
{
var dynamicMethod = new DynamicMethod("GetValue", typeof(int), new[] { typeof(A) }, typeof(A));
var ilGenerator = dynamicMethod.GetILGenerator();
ilGenerator.Emit(OpCodes.Ldarg_0);
ilGenerator.EmitCall(OpCodes.Call, GetValueMethod, null);
ilGenerator.Emit(OpCodes.Ret);
return (Func<A, int>)dynamicMethod.CreateDelegate(typeof(Func<A, int>));
}
private static Func<A, int> CreateGetValueExpressionFunc()
{
var instance = Expression.Parameter(typeof(A), "instance");
var getValueExpression = Expression.Lambda<Func<A, int>>(
Expression.Property(instance, ValueProperty),
instance);
return getValueExpression.Compile();
}
private static Action<A, int> CreateSetValueExpressionAction()
{
var instance = Expression.Parameter(typeof(A), "instance");
var value = Expression.Parameter(typeof(int), "value");
var setValueExpression = Expression.Lambda<Action<A, int>>(
Expression.Call(instance, ValueProperty.GetSetMethod(true), value),
instance, value);
return setValueExpression.Compile();
}
}
public class A
{
public int Value { get; set; }
}
public class Program
{
public static void Main()
{
Console.WriteLine(AccessBenchmarks.TestInstance);
var summary = BenchmarkRunner.Run<AccessBenchmarks>(DefaultConfig.Instance.WithSummaryStyle(new SummaryStyle(
cultureInfo: null, // use default
printUnitsInHeader: true,
printUnitsInContent: true,
sizeUnit: SizeUnit.B,
timeUnit: TimeUnit.Nanosecond,
printZeroValuesInContent: true,
ratioStyle: RatioStyle.Trend // this will print the ratio column
)));
}
}
在测试代码中，我们使用了BenchmarkDotNet来进行测试，测试的内容包括：
UnsafeAccessor：使用UnsafeAccessor特性来访问私有成员Reflection：使用反射访问私有成员Emit：使用Emit+动态方法访问私有成员ExpressionTrees：使用表达式树+委托来访问私有成员Direct：直接访问私有成员
测试结果如下图所示，可以看到使用UnsafeAccessor的性能是最好的，其次是直接访问私有成员，最差的是反射。这其实是出乎我的意料的，因为我认为它最多和直接访问私有成员的性能差不多，但是实际上它的性能比直接访问私有成员还要好，当然也有可能是统计的误差，0.0000ns这个尺度已经非常小了。
深入探究
看到这里我想大家都有很多疑问，实际上作者本人看到这里也是有很多的疑问，主要是这两个：
- 是什么原因让.NET社区想加入这个API？
- 它是如何做到访问私有成员的？
- 为什么性能会这么好？
新增功能的原因
如果要了解这个功能背后的东西，那么我们首先就要找到对应这个API的Issues，按照.NET社区的规范，所有的API都需要提交Issues，然后经过API Review，多轮讨论设计以后，才会开始开发。
首先我们定位到Issue是这一个，在Issue中我们可以了解到这个API主要是为了给System.Text.Json或EF Core这种需要访问私有成员的框架使用，因为目前它们都是基于Emit动态代码生成实现的，但是Emit不能在AOT中使用，现阶段只能使用慢速的反射API，所以迫切引入了一种零开销的私有成员访问机制。
https://github.com/dotnet/runtime/issues/86161
如何做到访问私有成员？
翻阅一下整个API提案Issue的讨论，我们可以找到具体实现的Issue，所以我们要了解它背后的原理的话，就需要跳转到对应的Issue。
在这里可以看到目前还没有做泛型的实现，非泛型的已经在下面链接中实现了，一个是为CoreCLR做的实现，另外一个是为Mono做的实现。
我们目前只关注CoreCLR，点开这个Issue。
https://github.com/dotnet/runtime/issues/86161
可以看到将这个任务拆成了几个部分，他们都在在一个PR中完成的，其中包括定义了UnsafeAccessor特性，在JIT中的实现，以及NativeAOT中进行了支持，另外编写了单元测试加入了有效的诊断方案。
那么来看看这个PR里面做了什么吧。
https://github.com/dotnet/runtime/pull/86932
由于PR非常的长，大家有兴趣可以点进去看看，低于8GB内存的小伙伴就要小心了。简单的来说这次修改主要就是两块地方，一块是JIT相关的修改，JIT这里主要是支持UnsafeAccessor和static extern int声明函数的用法，需要支持方法的IL Body为空，然后在JIT时根据特性为它插入代码。
首先我们来看JIT的处理，这块代码主要就是修改了jitinterface.cpp，可以看到它调用了TryGenerateUnsafeAccessor方法：
这个TryGenerateUnsafeAccessor方法实现在prestub.cpp中，这个prestub.cpp实现了一些预插桩的操作，TryGenerateUnsafeAccessor方法实现如下所示：
它针对UnsafeAccessorKind的不同枚举做了校验，防止出现运行时崩溃的情况：
然后调用了GenerateAccessor方法来生成IL：
在GenerateAccessor里面就是使用Emit进行代码生成：
所以从JIT的实现来看，它其实核心原理就是Emit代码生成，并没有太多特殊的东西。
另外是关于NativeAOT的实现，首先修改了NativeAotILProvider.cs这个类，这个类的主要作用就是在进行NativeAot的时候提供IL给JIT预先编译使用：
关键也是在GenerateAccessor方法里面，在这里生成了对应的IL代码：
总结一下，UnsafeAccessor实现原理还是使用的IL动态生成技术，只不过它是在JIT内部实现的。
为什么性能这么好？
那么它为什么性能要比我们在C#代码中自己写Emit要更好呢？其实原因也是显而易见的，我们自己编写的Emit代码中间有一层DynamicMethod的委托调用，增加了开销，而UnsafeAccessor它直接就是一个static extern int GetValueUnsafe(A a);方法，没有中间开销，而且它IL Body很小，可以被内联。
总结
通过对.NET8中新增的UnsafeAccessor特性的深入探究，我们得到了一些启示和理解。首先，UnsafeAccessor的引入并非无中生有，而是应运而生，它是为了满足System.Text.Json或EF Core这类框架在访问私有成员时的需求，因为它们目前大多基于Emit动态代码生成实现，但在AOT环境中无法使用Emit，只能依赖于效率较低的反射API。因此，UnsafeAccessor的引入，为我们提供了一种零开销的私有成员访问机制。
总的来说，UnsafeAccessor的引入无疑为.NET的发展增添了一抹亮色，它不仅提升了代码的执行效率，也为我们的编程方式提供了新的可能。我们期待在未来的.NET版本中，看到更多这样的创新和突破。