如何在中期总结中提升优化反射性能的效果？

本文共计2522个文字，预计阅读时间需要11分钟。

问题回顾+在上篇博客中，我介绍了优化反射的第一步：用委托调用替代直接反射调用。然而，这仅仅是反射优化过程的开始，因为新的问题出现了：如何保存大量的委托？

问题回顾

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

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

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

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

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

能不能不使用委托？

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

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