优化反射性能的总结

反射是一种很重要的技术,然而它与直接调用相比性能要慢很多,因此如何优化反射性能也就成为一个不得不面对的问题。 目前最常见的优化反射性能的方法就是采用委托:用委托的方式调用需要反射调用的方法(或者属性、字段)。

那么如何得到委托呢? 目前最常见也就是二种方法:Emit, ExpressionTree 。其中ExpressionTree可认为是Emit方法的简化版本, 所以Emit是最根本的方法,它采用在运行时动态构造一段IL代码来包装需要反射调用的代码, 这段动态生成的代码满足某个委托的签名,因此最后可以采用委托的方式代替反射调用。

用Emit方法优化反射

如果我们需要设计自己的数据访问层,那么就需要动态创建所有的数据实体对象,尤其是还要为每个数据实体对象的属性赋值, 这里就要涉及用反射的方法对属性执行写操作,为了优化这种反射场景的性能,我们可以用下面的方法来实现: 

public delegate void SetValueDelegate(object target, object arg);

public static class DynamicMethodFactory
{
    public static SetValueDelegate CreatePropertySetter(PropertyInfo property)
    {
        if( property == null )
            throw new ArgumentNullException("property");

        if( !property.CanWrite )
            return null;

        MethodInfo setMethod = property.GetSetMethod(true);

        DynamicMethod dm = new DynamicMethod("PropertySetter", null,
            new Type[] { typeof(object), typeof(object) },
            property.DeclaringType, true);

        ILGenerator il = dm.GetILGenerator();

        if( !setMethod.IsStatic ) {
            il.Emit(OpCodes.Ldarg_0);
        }
        il.Emit(OpCodes.Ldarg_1);

        EmitCastToReference(il, property.PropertyType);
        if( !setMethod.IsStatic && !property.DeclaringType.IsValueType ) {
            il.EmitCall(OpCodes.Callvirt, setMethod, null);
        }
        else
            il.EmitCall(OpCodes.Call, setMethod, null);

        il.Emit(OpCodes.Ret);

        return (SetValueDelegate)dm.CreateDelegate(typeof(SetValueDelegate));
    }
    
    private static void EmitCastToReference(ILGenerator il, Type type)
    {
        if( type.IsValueType )
            il.Emit(OpCodes.Unbox_Any, type);
        else
            il.Emit(OpCodes.Castclass, type);
    }
}

现在可以用下面的测试代码检验委托调用带来的性能改进: 

我用VS2008 (.net 3.5 , CLR 2.0) 测试可以得到以下结果: 

从结果可以看出:
1. 反射调用所花时间是直接调用的2629倍,
2. 反射调用所花时间是Emit生成的Set委托代码的82倍,
3. 运行Emit生成的Set委托代码所花时间是直接调用的31倍。

虽然Emit比直接调用还有30倍的差距,但还是比反射调用快80倍左右。

有意思的是,同样的代码,如果用VS2012 ( .net 4.5 , CLR 4.0) 测试可以得到以下结果: 
 
感谢zhangweiwen 在博客中展示了CRL 4.0对反射的性能改进, 在他的博客中还提供了一种采用表达式树的优化版本,以及包含一个泛型的强类型的版本。

Delegate.CreateDelegate也能创建委托

如果我们观察CreatePropertySetter的实现代码,发现这个方法的本质就是创建一个委托:

public static SetValueDelegate CreatePropertySetter(PropertyInfo property)
{
    // ..... 省略前面已贴过的代码
    return (SetValueDelegate)dm.CreateDelegate(typeof(SetValueDelegate));
}

看到这里,让我想起Delegate.CreateDelegate方法也能创建一个委托,例如:

OrderInfo testObj = new OrderInfo();
PropertyInfo propInfo = typeof(OrderInfo).GetProperty("OrderID");

Action<OrderInfo, int> setter = (Action<OrderInfo, int>)Delegate.CreateDelegate(
    typeof(Action<OrderInfo, int>), null, propInfo.GetSetMethod());

setter(testObj, 123);

显然,这是一种很直观的方法,可以得到一个强类型的委托。

然而,这种方法仅限有一种适用场景:明确知道要访问某个类型的某个属性或者方法,因为我们要提供类型参数。 例如:我要写个关键字过滤的HttpMoudle,它需要修改HttpRequest.Form对象的IsReadOnly属性,由于IsReadOnly在NameObjectCollectionBase类型中已申明为protected访问级别, 所以我只能反射操作它了,而且还需要很频繁的设置它。

在绝大部分反射场景中,例如数据访问层中从DataReader或者DataRow加载数据实体, 我们不可能事先知道要加载哪些类型,更不可能知道要加载哪些数据成员,因此就不可能给泛型委托的类型参数赋值, 这个方法看起来也就行不通了。

如果您不信的话,可以看下面修改后的代码:

OrderInfo testObj = new OrderInfo();
PropertyInfo propInfo = typeof(OrderInfo).GetProperty("OrderID");

//Action<OrderInfo, int> setter = (Action<OrderInfo, int>)Delegate.CreateDelegate(
//    typeof(Action<OrderInfo, int>), null, propInfo.GetSetMethod());

Action<object, object> setter = (Action<object, object>)Delegate.CreateDelegate(
    typeof(Action<object, object>), null, propInfo.GetSetMethod());

setter(testObj, 123);

Console.WriteLine(testObj.OrderID);

虽然能通过编译,但会在运行时报错:

在很多时候,我们只能在运行时得到以Type对象表示的类型,接受object类型才是通用的解决方案。 然而,前面的代码证明了我们不能简单将委托类型从Action<OrderInfo, int>修改为Action<object, object> 。

真的没有办法了吗?

虽然Emit已是很成熟的优化方案,可我还是希望试试 Delegate.CreateDelegate !

用Delegate.CreateDelegate优化反射

当我们用Delegate.CreateDelegate从一个MethodInfo对象创建委托时, 委托的签名必须和MethodInfo表示的方法签名相匹配(有可能不一致), 所以这种方法得到的委托注定是一种强类型的委托。 现在的问题是:我们在运行时构造与指定MethodInfo匹配的委托,如何将Type对象转换成泛型委托的类型参数?

为了解决这个问题,我采用了泛型类来解决泛型委托的类型参数问题:

public class SetterWrapper<TTarget, TValue> 
{
    private Action<TTarget, TValue> _setter;

    public SetterWrapper(PropertyInfo propertyInfo)
    {
        if( propertyInfo == null )
            throw new ArgumentNullException("propertyInfo");

        if( propertyInfo.CanWrite == false )
            throw new NotSupportedException("属性不支持写操作。");

        MethodInfo m = propertyInfo.GetSetMethod(true);
        _setter = (Action<TTarget, TValue>)Delegate.CreateDelegate(typeof(Action<TTarget, TValue>), null, m);
    }
    
    public void SetValue(TTarget target, TValue val)
    {
        _setter(target, val);
    }

我用泛型类把Delegate.CreateDelegate的问题解决了,但是如何创建这个类型的实例呢?
可以用Type.MakeGenericType()方法来解决:

public static object CreatePropertySetterWrapper(PropertyInfo propertyInfo)
{
    if( propertyInfo == null )
        throw new ArgumentNullException("propertyInfo");
    if( propertyInfo.CanWrite == false )
        throw new NotSupportedException("属性不支持写操作。");

    MethodInfo mi = propertyInfo.GetSetMethod(true);

    if( mi.GetParameters().Length > 1 )
        throw new NotSupportedException("不支持构造索引器属性的委托。");

    Type instanceType = typeof(SetterWrapper<,>).MakeGenericType(propertyInfo.DeclaringType, propertyInfo.PropertyType);
    return Activator.CreateInstance(instanceType, propertyInfo);
}

现在问题并没有结束,我又如何调用那些泛型类型实例的委托呢?
这里还有另一个问题要解决:调用方法需要支持object类型(满足通用性)。
我想到了定义一个接口来解决:

public interface ISetValue
{
    void Set(object target, object val);
}

然后让SetterWrapper实现ISetValue接口:

public class SetterWrapper<TTarget, TValue> : ISetValue
{
    // ..... 省略前面已贴过的代码

    void ISetValue.Set(object target, object val)
    {
        _setter((TTarget)target, (TValue)val);
    }
}

还有前面的CreatePropertySetterWrapper方法也需要再次调整返回值类型:

public static ISetValue CreatePropertySetterWrapper(PropertyInfo propertyInfo)
{
    // ..... 省略前面已贴过的代码
    return (ISetValue)Activator.CreateInstance(instanceType, propertyInfo);
}

考虑到有些特定场景下需要用反射的方式重复操作某一个属性,使用强类型的方法可以避免拆箱装箱,
所以我保留了前面的SetValue方法,让它提供更好的性能,满足一些特定场景的需要。
因此,现在的SetterWrapper类型有二种使用方法,可以提供二种性能不同的实现方法。

现在可以增加二段测试代码来测试它的性能了:

Console.Write("泛型委托花费时间:       ");
SetterWrapper<OrderInfo, int> setter3 = new SetterWrapper<OrderInfo, int>(propInfo);
Stopwatch watch4 = Stopwatch.StartNew();

for( int i = 0; i < count; i++ )
    setter3.SetValue(testObj, 123);

watch4.Stop();
Console.WriteLine(watch4.Elapsed.ToString());


Console.Write("通用接口花费时间:       ");
ISetValue setter4 = GetterSetterFactory.CreatePropertySetterWrapper(propInfo);
Stopwatch watch5 = Stopwatch.StartNew();

for( int i = 0; i < count; i++ )
    setter4.Set(testObj, 123);

watch5.Stop();
Console.WriteLine(watch5.Elapsed.ToString());

测试结果如下:

测试结果表明:强类型的泛型委托的速度比Emit生成的Set委托要快,但是基于通用接口的方法调用由于多了一层包装就比Emit方案要略慢一点。

完整的属性优化方案

前面介绍了为属性赋值这类反射案例的优化方案,那么怎么优化读取属性的反射操作呢?

其实思路差不多:
1. 在泛型类中调用Delegate.CreateDelegate,得到一个Func<TTarget, TValue>,
2. 定义一个IGetValue接口,提供一个方法: object Get(object target);
3. 让泛型类实现IGetValue接口
4. 提供一个工厂方法实例化泛型类的实例。
相关代码如下:

public interface IGetValue
{
    object Get(object target);
}

public static class GetterSetterFactory
{
    public static IGetValue CreatePropertyGetterWrapper(PropertyInfo propertyInfo)
    {
        if( propertyInfo == null )
            throw new ArgumentNullException("propertyInfo");
        if( propertyInfo.CanRead == false )
            throw new InvalidOperationException("属性不支持读操作。");

        MethodInfo mi = propertyInfo.GetGetMethod(true);

        if( mi.GetParameters().Length > 0 )
            throw new NotSupportedException("不支持构造索引器属性的委托。");
        
        Type instanceType = typeof(GetterWrapper<,>).MakeGenericType(propertyInfo.DeclaringType, propertyInfo.PropertyType);
        return (IGetValue)Activator.CreateInstance(instanceType, propertyInfo);
    }
}

public class GetterWrapper<TTarget, TValue> : IGetValue
{
    private Func<TTarget, TValue> _getter;

    public GetterWrapper(PropertyInfo propertyInfo)
    {
        if( propertyInfo == null )
            throw new ArgumentNullException("propertyInfo");

        if( propertyInfo.CanRead == false )
            throw new InvalidOperationException("属性不支持读操作。");

        MethodInfo m = propertyInfo.GetGetMethod(true);
        _getter = (Func<TTarget, TValue>)Delegate.CreateDelegate(typeof(Func<TTarget, TValue>), null, m);
    }
    
    public TValue GetValue(TTarget target)
    {
        return _getter(target);
    }
    object IGetValue.Get(object target)
    {
        return _getter((TTarget)target);
    }
}

前面的代码优化了实例属性的反射读写性能问题,但是还有极少数时候我们还需要处理静态属性,那么我们还需要再定义二个泛型类来解决:

public class StaticGetterWrapper<TValue> : IGetValue
{
    private Func<TValue> _getter;

    // ............
}

public class StaticSetterWrapper<TValue> : ISetValue
{
    private Action<TValue> _setter;

    // ............
}

前面看到的工厂方法也要调整,完整代码如下:

public static ISetValue CreatePropertySetterWrapper(PropertyInfo propertyInfo)
{
    if( propertyInfo == null )
        throw new ArgumentNullException("propertyInfo");
    if( propertyInfo.CanWrite == false )
        throw new NotSupportedException("属性不支持写操作。");

    MethodInfo mi = propertyInfo.GetSetMethod(true);

    if( mi.GetParameters().Length > 1 )
        throw new NotSupportedException("不支持构造索引器属性的委托。");

    if( mi.IsStatic ) {
        Type instanceType = typeof(StaticSetterWrapper<>).MakeGenericType(propertyInfo.PropertyType);
        return (ISetValue)Activator.CreateInstance(instanceType, propertyInfo);
    }
    else {
        Type instanceType = typeof(SetterWrapper<,>).MakeGenericType(propertyInfo.DeclaringType, propertyInfo.PropertyType);
        return (ISetValue)Activator.CreateInstance(instanceType, propertyInfo);
    }
}

委托方案的后续问题

前面的代码解决了属性的读写问题,然而使用它们还很不方便:每次都要创建一个ISetValue接口的实例,再调用它的方法。 其实这也是委托方案共有的问题:我们需要为每个属性的读写操作分别创建不同的委托,而且委托太零散了。

如何将属性与创建好的委托关联起来呢?(创建委托也是需要时间的)
我想所有人都会想到用字典来保存。
是的,好像也只有这一种方法了。
为了提高性能,我改进了工厂类,缓存了包含委托的实例,
为了方便使用前面的方法,我提供了一些扩展方法:

public static class GetterSetterFactory
{
    private static readonly Hashtable s_getterDict = Hashtable.Synchronized(new Hashtable(10240));
    private static readonly Hashtable s_setterDict = Hashtable.Synchronized(new Hashtable(10240));

    internal static IGetValue GetPropertyGetterWrapper(PropertyInfo propertyInfo)
    {
        IGetValue property = (IGetValue)s_getterDict[propertyInfo];
        if( property == null ) {
            property = CreatePropertyGetterWrapper(propertyInfo);
            s_getterDict[propertyInfo] = property;
        }
        return property;
    }

    internal static ISetValue GetPropertySetterWrapper(PropertyInfo propertyInfo)
    {
        ISetValue property = (ISetValue)s_setterDict[propertyInfo];
        if( property == null ) {
            property = CreatePropertySetterWrapper(propertyInfo);
            s_setterDict[propertyInfo] = property;
        }
        return property;
    }
}

public static class PropertyExtensions
{
    public static object FastGetValue(this PropertyInfo propertyInfo, object obj)
    {
        if( propertyInfo == null )
            throw new ArgumentNullException("propertyInfo");

        return GetterSetterFactory.GetPropertyGetterWrapper(propertyInfo).Get(obj);
    }

    public static void FastSetValue(this PropertyInfo propertyInfo, object obj, object value)
    {
        if( propertyInfo == null )
            throw new ArgumentNullException("propertyInfo");

        GetterSetterFactory.GetPropertySetterWrapper(propertyInfo).Set(obj, value);
    }
}

说明:我在缓存的设计上并没有使用泛型Dictionary,而是使用了Hashtable。
我承认在简单的单线程测试中,Dictionary要略快于Hashtable 。

再来测试一下FastSetValue的性能吧,毕竟大多数时候我会使用这个扩展方法。
我又在测试代码中增加了一段:

propInfo.FastSetValue(testObj, 123);
Console.Write("FastSet花费时间:       ");
Stopwatch watch6 = Stopwatch.StartNew();

for( int i = 0; i < count; i++ )
    propInfo.FastSetValue(testObj, 123);

watch6.Stop();
Console.WriteLine(watch6.Elapsed.ToString());

测试结果如下:

测试结果表明:虽然通用接口ISetValue将反射性能优化了37倍,但是最终的FastSetValue将这个数字减少到还不到7倍(在CLR4中还不到5倍)。

看到这个结果您是否也比较郁闷:优化了几十倍的结果,最后却丢了大头,只得到一个零头!

中间那30倍的时间是哪里消耗了?
1. Hashtable的查找时间。
2. 代码的执行路径变长了。

代码的执行路径变长了,我想所有人应该都能接受:为了简化调用并配合缓存一起工作,代码的执行路径确实变长了。

Hashtable的查找时间应该很快吧? 您是不是也这样想呢? 
为了看看Hashtable的查找时间,我又加了一点测试代码:

Hashtable table = new Hashtable();
table[propInfo] = new object();
Console.Write("Hashtable花费时间:      ");
Stopwatch watch7 = Stopwatch.StartNew();

for( int i = 0; i < count; i++ ) {
    object val = table[propInfo];
}
watch7.Stop();
Console.WriteLine(watch7.Elapsed.ToString());

现在运行测试代码的结果如下:

确实,大部分时间消耗在Hashtable的查找上!

缓存的线程并发问题

集合不仅仅只有查找开销,在多线程环境中,我们还要考虑并发性。

看到许多人做性能测试时,总是喜欢写个控制台程序,然后再来个for循环,执行多少万次!
我认为 这样的结果只能反映代码在单线程环境下的性能,在多线程下,结果可能会有较大的差别, 当然了,多线程测试的确很复杂,也很难得到准确的数字。 但是我们的设计不能不考虑多线程下的并发问题。

虽然我也在单线程环境下测试过Dictionary<TKey, TValue>的性能,的确要比Hashtable略好点。
但是MSDN上对Dictionary的线程安全的描述是这样的:

此类型的公共静态(在 Visual Basic 中为 Shared)成员是线程安全的。但不能保证任何实例成员是线程安全的。 

只要不修改该集合,Dictionary<(Of <(TKey, TValue>)>) 就可以同时支持多个阅读器。即便如此,从头到尾对一个集合进行枚举本质上并不是一个线程安全的过程。当出现枚举与写访问互相争用这种极少发生的情况时,必须在整个枚举过程中锁定集合。若要允许多个线程访问集合以进行读写操作,则必须实现自己的同步。

而MSDN对Hashtable的线程安全的描述却是:

Hashtable 是线程安全的,可由多个读取器线程和一个写入线程使用。多线程使用时,如果只有一个线程执行写入(更新)操作,则它是线程安全的,从而允许进行无锁定的读取(若编写器序列化为 Hashtable)。若要支持多个编写器,如果没有任何线程在读取 Hashtable 对象,则对 Hashtable 的所有操作都必须通过 Synchronized 方法返回的包装完成。 

从头到尾对一个集合进行枚举本质上并不是一个线程安全的过程。即使一个集合已进行同步,其他线程仍可以修改该集合,这将导致枚举数引发异常。若要在枚举过程中保证线程安全,可以在整个枚举过程中锁定集合,或者捕捉由于其他线程进行的更改而引发的异常。

显然,二个集合都不能完全支持多线程的并发读写。
虽然Hashtable提供同步包装的线程安全版本,但是内部还是在使用锁来保证同步的!
没办法,在多线程环境中,任何复杂数据结构都有线程安全问题。

如何保证集合在并发操作中数据的同步呢?
是lock还是ReaderWriterLock?
显然前者的实现较为简单,所以它成了绝大多数人的首选。
在.net4中,ConcurrentDictionary是另一个新的首选方法。

由于Dictionary只支持并发的读操作,所以只要涉及到写操作,它就不安全了,
因此最安全地做法也只好在 读和写 操作上都加lock,否则就不安全了。

而Hashtable则不同,它的内部数据结构支持一个线程写入的同时允许多个线程并发读取,所以只要在写操作上加lock就可以实现线程同步, Hashtable的线程安全版本也就是这样实现的。 这也是我选择Hashtable的原因。

小结

在这篇博客中,我演示了二种不同的反射优化方法:
1. 基于Emit的动态生成符合委托签名的IL代码。
2. 使用Delegate.CreateDelegate直接创建委托。

这是二种截然不同的思路:
1. Emit方法,需要先定义一个委托签名,然后生成符合委托签名的IL代码。
2. CreateDelegate可以直接生成委托,但需要借用泛型类解决委托的类型参数问题,最后为了能通用,需要以接口方式调用强类型委托。

虽然我们可以使用任何一种方法得到委托,但是我们需要操作多少属性呢? 显然这是一个无解的问题,我们只能为每个属性创建不同的委托。所以新的问题也随之产生: 我们如何保存那些委托?如何让它们与属性关联起来? Dictionary或者Hashtable或许是较好的选择(.net 3.5),然而,这些对象内部的数据结构在查找时,并不是零成本, 它们会消耗优化的大部分成果。 另外,在实现缓存委托的问题上,并发问题也是值得我们考虑的,不高效的并发设计还会让优化的成果继续丢失!

所以,我认为优化反射是个复杂问题,至少有3个环节是需要考虑的:
1. 如何得到委托?
2. 如何缓存委托?
3. 如何支持并发?

得到委托是容易的,但它只是一个开始!

上篇博客中,我介绍了优化反射的第一个步骤:用委托调用代替直接反射调用。
然而,那只是反射优化过程的开始,因为新的问题出现了:如何保存大量的委托?

如果我们将委托保存在字典集合中,会发现这种设计会浪费较多的执行时间,因为这种设计会引发三个新问题:
1. 代码的执行路径变长了。
2. 字典查找是有成本开销的。
3. 字典集合的并发读写需要锁定,会影响并发性。

再来回顾一下上次的测试结果吧:

虽然通用接口ISetValue将反射性能优化了37倍,但是最终的FastSetValue将这个数字减少到还不到7倍(在CLR4中还不到5倍)。
难道您不觉得遗憾吗?

再看看直接调用与反射调用的对比,它们的速度相差了上千倍!

能不能不使用委托?

既然委托最后引出了三个难以解决的问题,导致优化后速度比直接调用差距太远,那我们能不能不使用委托呢?

委托调用并不是优化反射的唯一方案,我们还有其它方法,
之所以委托调用能成为常见的优化方案是因为它比较简单。

假如我需要用客户端提交的数据来填充某个数据对象,考虑到代码的通用性,我会用反射写成这样:

/// <summary>
/// 从HttpRequest加载obj所需的数据
/// </summary>
/// <param name="request"></param>
/// <param name="obj"></param>
public static void LoadDataFromHttpRequest(HttpRequest request, object obj)
{
    PropertyInfo[] properties = obj.GetType().GetProperties();
    foreach( PropertyInfo p in properties ) {
        // 这里只是示意代码,假设数据处理不会有异常。
        object val = Convert.ChangeType(request[p.Name], p.PropertyType);
        p.FastSetValue(obj, val);
    }
}

如果我事先知道要加载已知的数据类型,代码会写成这样:

public static void LoadDataFromHttpRequest(HttpRequest request, OrderInfo order)
{
    // 这里只是示意代码,假设数据处理不会有异常。
    order.OrderID = int.Parse(request["OrderID"]);
    order.OrderDate = DateTime.Parse(request["OrderDate"]);
    order.SumMoney = decimal.Parse(request["SumMoney"]);
    order.Comment = request["Comment"];
    order.Finished = bool.Parse(request["Finished"]);
}

显然,第二段代码运行效率更快(尽管第一段代码调用FastSetValue优化了速度)。

大家都知道反射性能较差,直接调用性能最好,那么能不能在运行时不使用反射呢?

的确,使用反射是因为我们事先不知道要处理哪些类型的对象,因此不得不用反射, 另外,反射的代码也更通用,写一个方法可以加载所有的数据类型,可认为是一劳永逸的方法。 不过,就算我们事先不知道要处理哪些对象类型,但是只要使用反射,我们完全可以知道任何一个类型包含哪些数据成员, 还能知道这些数据成员的数据类型,这一点不用怀疑吧? 既然我们用反射可以知道所有的类型定义信息,我们是否可以参照代码生成器的思路去生成代码呢? 我们可以参照前面第二段代码,为【需要处理的类型】生成直接调用的代码,这样不就彻底解决了反射性能问题了吗? 生成代码的过程,其实也就是个字符串的拼接过程,难度并不大,只是比较复杂而已。

如果前面的答案都是肯定的,那么现在只有一个问题了:我们能在运行时执行拼接生成的字符串代码吗?

答案也是肯定的:能!

CodeDOM:在运行时编译代码

回忆一下我们编写的ASPX页面,它们并不是C#代码,它们本质上就是一个文本文件, 我们可以写入一些HTML标签,还有些标签上加了 runat="server" 属性, 我们还可以在页面中插入一些C#代码片段,尽管它们不是我们编译后的DLL文件,然而它们就是运行起来了! 要知道ASP.NET不是ASP,ASP是解释性的脚本语言,而ASP.NET是以编译方式运行的, 所以,每个ASPX页面文件最后都是运行编译后的结果。

假设我有下面一段文本(文本的内容是一段C#代码):

using System;
using System.Collections.Generic;
using System.Text;
using System.Reflection;

namespace OptimizeReflection
{
    public class DemoClass
    {
        public int Id { get; set; }

        public string Name;

        public int Add(int a, int b)
        {
            return a + b;
        }
    }

    public class 用户手册
    {
        public static void Main()
        {
            // OptimizeReflection 这个类库提供了一些扩展方法,它们用于优化常见的反射场景
            // 下面是一些相关的演示示例。
            
            // 对于属性的读写操作、方法的调用操作,还提供了性能更好的强类型(泛型)版本,可参考Program.cs

            Type instanceType = typeof(DemoClass);
            PropertyInfo propertyInfo = instanceType.GetProperty("Id");
            FieldInfo fieldInfo = instanceType.GetField("Name");
            MethodInfo methodInfo = instanceType.GetMethod("Add");

            // 1. 创建实例对象
            DemoClass obj = (DemoClass)instanceType.FastNew();

            // 2. 写属性
            propertyInfo.FastSetValue(obj, 123);
            propertyInfo.FastSetValue2(obj, 123);

            // 3. 读属性
            int a = (int)propertyInfo.FastGetValue(obj);
            int b = (int)propertyInfo.FastGetValue2(obj);

            // 4. 写字段
            fieldInfo.FastSetField(obj, "Fish Li");

            // 5. 读字段
            string s = (string)fieldInfo.FastGetValue(obj);

            // 6. 调用方法
            int c = (int)methodInfo.FastInvoke(obj, 1, 2);
            int d = (int)methodInfo.FastInvoke2(obj, 3, 4);

            Console.WriteLine("a={0}; b={1}; c={2}; d={3}; s={4}", a, b, c, d, s);
        }
    }
}

您可以把上面这段文本想像成前面第二个版本的LoadDataFromHttpRequest方法,如果我们在运行时使用反射也能生成那样的代码, 现在就差把它编译成程序集了。下面的代码演示了如何将一段文本编译成程序集的过程:

string code = null;

// 1. 生成要编译的代码。(示例为了简单直接从程序集内的资源中读取)
Stream stram = typeof(CodeDOM).Assembly
            .GetManifestResourceStream("TestOptimizeReflection.用户手册.txt");
using( StreamReader sr = new StreamReader(stram) ) {
    code = sr.ReadToEnd();
}

//Console.WriteLine(code);

// 2. 设置编译参数,主要是指定将要引用哪些程序集
CompilerParameters cp = new CompilerParameters();
cp.GenerateExecutable = false;
cp.GenerateInMemory = true;
cp.ReferencedAssemblies.Add("System.dll");
cp.ReferencedAssemblies.Add("OptimizeReflection.dll");

// 3. 获取编译器并编译代码
// 由于我的代码使用了【自动属性】特性,所以需要 C# .3.5版本的编译器。
// 获取与CLR匹配版本的C#编译器可以这样写:CodeDomProvider.CreateProvider("CSharp")

Dictionary<string, string> dict = new Dictionary<string, string>();
dict["CompilerVersion"] = "v3.5";
dict["WarnAsError"] = "false";

CSharpCodeProvider csProvider = new CSharpCodeProvider(dict);
CompilerResults cr = csProvider.CompileAssemblyFromSource(cp, code);

// 4. 检查有没有编译错误
if( cr.Errors != null && cr.Errors.HasErrors ) {
    foreach( CompilerError error in cr.Errors )
        Console.WriteLine(error.ErrorText);

    return;
}

// 5. 获取编译结果,它是编译后的程序集
Assembly asm = cr.CompiledAssembly;

整个过程分为5个步骤,它们已用注释标识出来了,这里不再重复了。

如何调用编译结果

前面的代码把一段文本字符串编译成了程序集,现在还有最后一个问题:如何调用编译结果?

答案:有二种方法,
1. 直接调用方法。
2. 实例化程序集中的类型,以接口方式调用方法。
其实这二种方法都需要使用反射,用反射定位到要调用的类型和方法。

第一种方法要求在生成代码时,生成的类名和方法名是明确的,在调用方法时,我们有二个选择:
1. 用反射的方式调用(这里只是一次反射)。
2. 为方法生成委托(用上篇博客介绍的方法),然后基于委托调用。

第二种方法要求在生成代码时,首先要定义一个接口,保证生成的代码能实现指定的接口,
然而用反射找到要调用的类型名称,用反射或者委托调用构造方法创建类型实例,最后基于接口去调用。
我们熟悉的ASPX页面就是采用了这种方式来实现的。

这二种方法也可以这样区分:
1. 如果生成的方法是静态方法,应该选择第一种方法。
2. 如果生成的方法是实例方法,那么选择第二种方法是合理的。

对于前面的示例,我采用了第一种方法了,因为类名和方法名称都是事先确定的而且实现起来比较简单。

// 6. 找到目标方法,并调用
Type t = asm.GetType("OptimizeReflection.用户手册");
MethodInfo method = t.GetMethod("Main");
method.Invoke(null, null);



能不能不使用委托? 如何用好CodeDOM?

用Delegate优化反射的缺点

在评价委托方案时,我认为有必要细分一下委托方案:
1. 强类型委托,例如:Action<TTarget, TValue>
2. 弱类型委托,例如:Action<object, object>

它们的优点分别是:
强类型委托:速度快,已经最接近直接调用的性能,然而它的缺点是 不通用。 
弱类型委托:
比较通用,且经过一些代码封装后,使用方便,但是 封装后的性能会变差。

用Delegate优化反射的优点

优点有二个:
1. 实现简单,不管是使用Emit, ExpressionTree还是CreateDelegate,代码量都不大。
2. 方法通用,使用弱类型委托,我们可以封装出很容易使用的API,且适用于任何项目。

用CodeDOM优化反射的优点

最大的,也是唯一的优点就是:性能好。
由于生成的是直接调用的代码,因此最终运行的是直接调用的代码,所以没有性能损耗。
另外,代码生成器可以决定最终生成的代码质量,代码生成器越优秀,代码的性能也会更优秀。

注意:当使用这种技术时,不同人可能会有不同的使用方法,最终可以得到性能不同的结果, (理论上)最坏情况下可能比委托还差。

如果希望借助这种优化方式实现最好的性能,需要做好二件事情:
1. 保证最终生成的代码质量是最优的。
2. 编译方式的设计要合理(用好CodeDOM)。

如何保证最终生成的代码质量是最优的,我给不了建议,需要您自己去思考,
我们接着讨论第2点。

如何用好CodeDOM?

虽然采用动态编译技术,我们可以生成直接调用的代码来代替反射调用,这样就不会有任何性能损失。
但是,还有一个问题也是需要考虑的:我该以什么粒度去生成代码?
1. 是为每个反射调用生成代码?
2. 还是为每个类型批量生成一段代码?
3. 还是为一堆类型大批量的生成一批代码?

由于动态编译的结果并不能直接调用,我们只能借助委托或者接口的方式去调用,
所以如果每次代码生成的粒度较小,将会产生大量的程序集,也会消耗较多的编译器启动时间,
因此,这并不是高效的做法。高效的做法应该是一次尽可能生成较多的代码。

除此之外,还有一个问题也要考虑:当需要循环调用编译结果时,该怎么办?
对于这类场景,我建议在生成代码时,把循环过程直接生成出来,最终只用一次调用编译结果完成整个调用过程。
例如我们可以为数据访问层生成这样类似的代码,把循环、创建实体对象,以及给属性赋值的所有操作全部包含进来:

public static List<Product> LoadProduct(DbDataReader reader)
{
    List<Product> list = new List<Product>();

    while( reader.Read() ) {
        Product p = new Product();
        p.ProductID = (int)reader["ProductID"];
        p.ProductName = reader["ProductName"].ToString();
        p.CategoryID = (int)reader["CategoryID"];
        p.Unit = reader["Unit"].ToString();
        p.UnitPrice = (decimal)reader["UnitPrice"];
        p.Remark = reader["Remark"].ToString();
        p.Quantity = (int)reader["Quantity"];
        list.Add(p);
    }
    return list;
}

如果我们生成了这样的代码,最后只需要一次调用,就可以代替以前上百次的委托调用以及缓存查找,锁的冲突也会减少到最低。

用CodeDOM优化反射的缺点

缺点有三个:
1. 方法不通用,需要针对不同的类型,不同的数据源生成不同的直接调用代码,因此难以通用化。
2. 复杂性较高,由于是生成直接调用的代码,且数据类型及格式未知,因此需要周密的考虑各种情况,复杂性也随之增高。
3. 难以封装,由于编译的结果是一个程序集,它并不能直接调用,还需要借助其它的方式来调用,所以难以实现较为通用的封装。

能不能不使用委托?

既然我们可以在运行时动态生成代码并编译它们,达到代替反射的目标,因此也就不需要委托调用的优化方法了。
那么,委托还有意义吗? 或者说:优化反射时能不能不使用委托?

在上篇博客中,我演示过动态编译的方法。
由于动态编译的结果是一个程序集,它本身是不能直接调用,我们需要采用其它的方法去调用它。
那篇博客给大家介绍了二种方法,其中一种方法就是用委托去调用程序集中的方法。
由于那些在运行时生成的代码是由我们的代码生成的,方法的签名我们可以控制,
所以,这时调用 Delegate.CreateDelegate 方法您不会遇到任何麻烦, 
因此,通过强类型的委托来调用CodeDOM的编译结果,这种配合会非常方便。
正是由于这个原因,当您选择生成static类型的方法时,委托还是必须的,此时委托和CodeDOM将是一种共存关系。

如果您在生成代码时采用了接口的设计方案,那么委托就没有必要使用了。

根据反射密集程度选择优化方法

优化反射,到底是选择CodeDOM,还是选择Delegate ?
我认为要按不同的反射密集程度分开讨论。

1. 反射密集程度低:例如:一次HTTP请求过程,我们的代码只需要一二次反射操作,
或者对于桌面程序来说,在响应用户点击事件时,使用了几次反射调用。
在这类场景中,反射的密集程度就可认为是很低的。那么这种情况下该如何优化呢?
我的答案是:优不优化都无所谓,因为反射并不是慢得不能接受。
反射的速度到底有多慢? 我们还是来看一下以前做过的测试吧:

从这张图片(来源于本系列的第一篇)可以看出,用反射的方式执行属性赋值操作,就算运行1000000次,也只花了1.2秒! 要知道我的测试机器是3年前买的笔记本电脑,如果换成目前专业的服务器,消耗的时间会更少, 因此,这类反射的优化价值不大。 当然了,如果您愿意优化它们那也不是件坏事。

2. 反射密集程度高:例如,数据访问层的应用中, 当一次加载一个实体列表时,反射次数是分页数量乘以字段数量,再加上创建实体对象数量。 这个数量很容易达到百次级别,而且一次HTTP请求过程中,可能需要加载多种数据,那么反射次数就很可观了。 我们经常感觉各种序列化和反序列化程序的执行效率不高,这与反射有着很直接的关系。 不过,我们通常不需要编写序列化反序列化程序,也只能被迫接受它们的性能了。 因此,对于反射密集程度很高的代码,如果优化手段不理想,肯定会影响性能。

3. 当处于前二者之间的密集程度。由于这类场景实在是无法定性衡量, 而且不同人对性能敏感程度也不一样,或者由于不同的应用对性能的要求也不同。
因此,这类场景的范围只能靠自己去评估了,优化方式也只能是自行选择了:
1. 关注性能的话,就选择CodeDOM,
2. 否则就选择Delegate吧,毕竟这种方法使用简单。

CodeDOM优化的误区

1. CodeDOM真能让程序的性能提升千倍吗?
根据前面的截图,我们知道直接调用比反射调用的性能要提升千倍, 因此是不是可以认为采用动态编译的方法,程序的性能就能提升千倍? 
答案是否定的。举例来说,拿创建实体对象的场景来说,虽然反射调用所花时间和直接调用时间差了千倍, 即使我们用动态编译代替了反射,但是给属性赋值前,我们需要为那些属性获取数据。 然而,获取数据的操作极有可能比反射更慢,因此,对于整个过程来说,我们能优化的只是其中的一小部分, 所以,当我们测试整个过程时,性能不会提升到千倍。 性能提升多少倍,取决于反射在整个过程中所花时间的比例。

2. CodeDOM方案一定比Delegate方案快。 
答案也是否定的,前面已经解释过了,如果您为每个反射调用去生成一个方法(委托的思路),那么最后还是需要一个委托或者一个接口来调用, 而且此时还要加上编译器的启动时间,最终的性能将比委托更慢。

反射优化的总结

反射优化的根本方法只有一条路:避开反射。
然而,避开的方法可分为二种:
1. 用委托去调用。(绕弯子)
2. 生成直接调用代码,替代反射调用。(直截了当)

这二种方法都有优缺点,我认为选择哪种方法应该根据反射场景来决定:
1. 调用目标明确(名称和类型都是已知):强类型委托方法是较好的选择。
2. 调用目标不明确,且调用程度密集:动态编译方法是最好的选择。
3. 其它情况:可以用弱类型委托,或者不优化。



阅读更多
想对作者说点什么?

博主推荐

换一批

没有更多推荐了,返回首页