Attribute操作的性能优化方式
Attribute是.NET平台上提供的一种元编程能力,可以通过标记的方式来修饰各种成员。无论是组件设计,语言之间互通,还是最普通的框架使用,现在已经都离不开Attribute了。迫于Attribute的功能的重要性(Kent Beck认为NUnit比早期JUnit设计的好,一个主要方面便是利用了Attribute),Java语言也在5.0版本中引入了与Attribute类似的Annotation概念。不过Attribute说到底也是一种反射操作,平时正常使用不会带来问题,但是密集的调用还是对性能有一定影响的。这次我们就来总结看看我们究竟可以如何回避Attribute操作的一些性能问题。
假设我们有一个Attribute,它定义在一个类型上:
[AttributeUsage(AttributeTargets.Class, AllowMultiple = true, Inherited = true)] public class TestAttribute : Attribute { public TestAttribute(string prop) { this.Prop = prop; } public TestAttribute() { } public string Prop { get; set; } } [Test("Hello World")] [Test(Prop = "Hello World")] public class SomeClass { }
那么,如果我们需要获得SomeClass类型上所标记的TestAttribute,我们一般会使用Type对象的GetCustomAttributes方法。那么在其中又发生了什么呢?
通过.NET Reflector来追踪其中实现,会发现这些逻辑最终是由CustomAttribute的GetCustomAttributes方法完成的,感兴趣的朋友们可以找到那个最复杂的重载。由于实现有些复杂,我没有看懂完整的逻辑,但从关键的代码上可以看出,它其实是使用了Activator.CreateInstance方法创建对象,并且使用反射对Attribute对象的属性进行设置。于是我便打算了解一下这些反射操作占整个GetCustomAttributes方法的多大比重:
CodeTimer.Time("GetCustomAttributes", 1000 * 100, () => { var attributes = typeof(SomeClass).GetCustomAttributes(typeof(TestAttribute), true); }); CodeTimer.Time("Reflection", 1000 * 100, () => { var a1 = (TestAttribute)Activator.CreateInstance(typeof(TestAttribute), "Hello World"); var a2 = (TestAttribute)Activator.CreateInstance(typeof(TestAttribute)); typeof(TestAttribute).GetProperty("Prop").SetValue(a2, "Hello World", null); });
结果如下:
GetCustomAttributes Time Elapsed: 2,091ms CPU Cycles: 5,032,765,488 Gen 0: 43 Gen 1: 0 Gen 2: 0 Reflection Time Elapsed: 527ms CPU Cycles: 1,269,399,624 Gen 0: 40 Gen 1: 0 Gen 2: 0
可以看出,虽然GetCustomAttributes方法中使用了反射进行对象的创建和属性设置,但是它的大部分开销还是用于获取一些元数据的,它们占据了3/4的时间,而反射的开销其实只占了1/4左右。这就有些令人奇怪了,既然是静态的元数据,为什么.NET Framework不对这些数据进行缓存,而是每次再去取一次呢?即便是我们不应该缓存最后得到的Attribute对象,但是用于构造对象的“信息”是完全可以缓存下来的。
事实上.NET Framework事实上已经给出了足够的信息,那便是CustomAttributeData的GetCustomAttributes方法,它返回的是IList<CustomAttributeData>对象,其中包含了构造Attribute所需要的全部信息。换句话说,我完全可以根据一个CustomAttributeData来“快速构建”Attribute对象:
public class AttributeFactory { public AttributeFactory(CustomAttributeData data) { this.Data = data; var ctorInvoker = new ConstructorInvoker(data.Constructor); var ctorArgs = data.ConstructorArguments.Select(a => a.Value).ToArray(); this.m_attributeCreator = () => ctorInvoker.Invoke(ctorArgs); this.m_propertySetters = new List<Action<object>>(); foreach (var arg in data.NamedArguments) { var property = (PropertyInfo)arg.MemberInfo; var propertyAccessor = new PropertyAccessor(property); var value = arg.TypedValue.Value; this.m_propertySetters.Add(o => propertyAccessor.SetValue(o, value)); } } public CustomAttributeData Data { get; private set; } private Func<object> m_attributeCreator; private List<Action<object>> m_propertySetters; public Attribute Create() { var attribute = this.m_attributeCreator(); foreach (var setter in this.m_propertySetters) { setter(attribute); } return (Attribute)attribute; } }
AttributeFactory利用了FastReflectionLib,将ConstructorInfo和PropertyInfo封装成性能很高的ConstructorInvoker和PropertyAccessor对象,这样使用起来便有数量级的性能提高。我们再来进行一番测试:
var factories = CustomAttributeData.GetCustomAttributes(typeof(SomeClass)) .Where(d => d.Constructor.DeclaringType == typeof(TestAttribute)) .Select(d => new AttributeFactory(d)).ToList(); CodeTimer.Time("GetCustomAttributes", 1000 * 100, () => { var attributes = typeof(SomeClass).GetCustomAttributes(typeof(TestAttribute), true); }); CodeTimer.Time("AttributeFactory", 1000 * 100, () => factories.ForEach(f => f.Create()));
结果如下:
GetCustomAttributes Time Elapsed: 2,131ms CPU Cycles: 5,136,848,904 Gen 0: 43 Gen 1: 43 Gen 2: 0 Attribute Factory Time Elapsed: 18ms CPU Cycles: 44,235,564 Gen 0: 4 Gen 1: 4 Gen 2: 0
在这里,我们先获得SomeClass中所有定义过的CustomAttributeData对象,然后根据其Constructor的类型来判断哪些是用于构造TestAttribute对象的,然后用它们来构造AttributeFactory。在实际使用过程中,AttributeFactory实例可以缓存下来,并反复使用。这样的话,我们即可以每次得到新的Attribute对象,又可以避免GetCustomAttributes方法所带来的莫名其妙的开销。
事实上,我们完全可以利用这个方法,来实现一个性能更高的GetCustomAttributesEx方法,它的行为可以和.NET自带的GetCustomAttributes完全一致,但是性能可以快上无数——可能是100倍。不过,这个方法虽然不难编写,但比较麻烦。因为CustomAttributeData只能用于获得“直接定义”在某个成员上的数据,而实际情况是,我们往往还必须根据某个Attribute上标记的AttributeUsage的AllowMultiple和Inherited属性来决定是否要遍历整个继承链。只有这般,我们才能百分之百地重现GetCustomAttribute方法的行为。
不过我们在这里有个优势,那便是“静态”。一旦“静态”,我们便可以为某个特定的场景,用“肉眼”判断出特定的处理方式,这样便不需要一个非常通用的GetCustomAttributeEx方法了。例如在实际使用过程中,我们可以可以发现某个Attribute的Inherited属性为false,那么我们便可以免去遍历继承链的麻烦。
最后还有两点可能值得一提:
除了Type,Assembly等成员自带的GetCustomAttributes方法之外,Attribute类也有些静态GetCustomAttributes方法可用于获取Attribute对象。但是,通过.NET Reflector,我们可以发现,Attribute类中的静态方法,最终还是委托给各自的实例方法,因此不会有性能提高。唯一区别对待的是ParameterInfo——不过我没搞懂为什么那么复杂,感兴趣的朋友可以自行探索一番。
如果仅仅是判断一个成员是否定义了某个特定类型的Attribute对象,那么可以使用Attribute.IsDefined静态方法。它的性能比GetCustomAttributes后再判断数组的Length要高效许多倍。不过个人认为这点倒并不是非常重要,因为这原本就是个静态的信息,即便是我们使用较慢的GetCustomAttributes方法来进行判断,也可以把最终的true或false结果进行缓存,这自然也不会有性能问题了。
我们之所以要反复调用GetCustomAttributes方法,就是因为每次得到的Attribute对象都是新建的,因此在某些场景下可能无法缓存它们。不过现在已经有了现在更快的做法,在这方面自然也就不会有太大问题了。