C#反射及元数据性能问题.pdfVIP

在开始谈论性能问题之前，有必要首先理清几个基本点。我们谈C# ，就是在谈.NET Framework(或者更准确 一点是CLR ，因为.NET Framework 除了CLR 还包括BCL);谈.NET Framework(CLR)，也就是在谈C# 。因为支撑 C#语法之后的就是整个CLR 的机制。因此，我说C#性能不好，和说CLR 性能不好，说的是一个事情(就像说 Java 性能不好，就是说JVM 性能不好一样) 。我不希望在我下面说C#某个地方性能不好的时候，再有论者 立即指出来“那不是C# 的问题，那是CLR 的问题，或者.NET Framework 的问题”——如果对C#和.NET 还停 留在这个认识上，请先去读读Jeffrey Richter 的《CLR via C#》一书，再来看我下面的文章。 另外，我说C#性能有问题，仅针对C#而言，与我对其他语言的态度无关。我既不是Java 的支持者( 因 为Java 的性能比C#还慢) ，也不是C++ 的支持者(C++太过臃肿复杂) ，也不是C 的支持者(没有基本的面向对 象抽象和垃圾回收) 。我既不喜欢任何语言，也不讨厌任何语言。编程语言在我只是一个工具——我只是希 望这个工具是把锋利的牛刀，而不是把功能齐全的瑞士小刀。 最后我不是毫无选择地反对“新功能”，我反对的是“添加的功能、没有重大抽象意义，却带来性能损 失”，如果有“提高性能的新功能”——比如并发编程，或者“对管理软件复杂度”有重大意义，同时性能 损失很小很小——比如面向对象，那我举双手赞成。” 在理清了前面几个基本点之后，下面开始来针对我前文说过的一些问题一一“讲原理”。这篇文章中， 我首先来剖析反射的性能问题。 反射的两大类性能问题 【一】反射绑定与调用——使用反射带来的性能问题 反射的绑定与调用性能差，我想大概做过.NET 开发的人都不会怀疑这一点。但是我还是希望那些严肃 的 程 序 员 认 真 看 看 微 软 CLR 程 序 经 理 Joel Pobar 在 MSDN 上 的 这 篇 文 章 ： Dodge Common Performance Pitfalls to Craft Speedy Applications /en-us/magazine/cc163759.aspx，清楚理解反射绑定与调用的效率到底为什么那么 差?有多差?差在哪里? 限于篇幅关系，我简单在这里总结一下，反射绑定与调用的性能问题(具体原理，大家参照MSDN 这篇 文章) ： 首先要经过一个绑定过程，非常耗时(用字符串名称和 metadata 里面的字符串进行比对，字符串查找 的算法大家都知道是很慢的操作) 然后要进行参数个数、类型等的校验;如果不匹配还要搜索可能的类型转换 进行CAS 代码访问安全的验证，看允不允许调用。 以上几个工作，如果不用反射应该是由C#编译器负责在编译时检查的。但是现在如果用反射，全都放 到了运行时检查。 这其中会产生一大堆的临时对象( 比如MemberInfo Cache) ，给垃圾收集器造成巨大负担 纵然有一些对反射绑定和调用的cache 优化策略，Joel Pobar 在这篇文章中给的最大的建议还是：能不 用反射，则不用反射，因为性能成本太高。 结论：反射调用的性能成本很高(参见msdn 文章中中图2 Relative Performance of Invocation Mechanism) 。 我想这些性能问题，大家都会认可。但有些朋友会说“我.NET 程序中用反射的很少啊? ”，首先且不论 你用的少不少，但是微软开发的很多Application Framework 对反射的使用现在越来越多，比如大量使用反 射 “绑定与调用”的例子(注意是大量，不是一点点!)： WPF 和Silverlight 中的XAML 序列化-反序列化，依赖属性，数据绑定 ASP.NET MVC 中路由、控制器，视图等的匹配查找(反射绑定)和调用(反射调用) WCF 分布式通信中大量的实例激活，方法调用，序列化与反序列化 WF 中大量的工作流流程激活、控制、调用 „„„..上面几乎把.NET 平台的主要应用框架都包括了，不用再举更多例子了吧?谁能脱离这些应用框 架去写程序? 所以说，你用反射用的少，并不代表你最后做出的软件用反射的少(你的软件的代码不可能全都是自己 写的，很多都是依附于微软的Ap