阅读目录

• 开始

• 用Delegate优化反射的缺点

• 用Delegate优化反射的优点

• 用CodeDOM优化反射的优点

• 如何用好CodeDOM？

• 用CodeDOM优化反射的缺点

• 能不能不使用委托？

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

• CodeDOM优化的误区

• 反射优化的总结

在前二篇博客中，我分别介绍了二种优化反射的方法：
1. Delegate：委托。
2. 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. 其它情况：可以用弱类型委托，或者不优化。

点击此处下载示例代码

如果，您认为阅读这篇博客让您有些收获，不妨点击一下右下角的【推荐】按钮。
如果，您希望更容易地发现我的新博客，不妨点击一下右下角的【关注 Fish Li】。
因为，我的写作热情也离不开您的肯定支持。

感谢您的阅读，如果您对我的博客所讲述的内容有兴趣，请继续关注我的后续博客，我是Fish Li 。