书接上回,我们讨论了在.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这个尺度已经非常小了。
看到这里我想大家都有很多疑问,实际上作者本人看到这里也是有很多的疑问,主要是这两个:
如果要了解这个功能背后的东西,那么我们首先就要找到对应这个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版本中,看到更多这样的创新和突破。