【IT168评论】在开始谈论性能问题之前，有必要首先理清几个基本点。我们谈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 http://msdn.microsoft.com/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平台的主要应用框架都包括了，不用再举更多例子了吧?谁能脱离这些应用框架去写程序?
所以说，你用反射用的少，并不代表你最后做出的软件用反射的少(你的软件的代码不可能全都是自己写的，很多都是依附于微软的Application Framework，只要这些Application Framework很重地使用了反射，那么你的软件也就很重的使用了反射)
但有朋友会立即指出“我不用WPF/SL，不用WCF、不用WF、不用ASP.NET MVC，类库都是自己写，代码全都是自己写，保证反射用的很少，甚至确保压根没有使用反射，这些性能负担不久没有了吗?”这个问题很好! 也是前面谈到.NET各种功能带来的性能问题的时候，很多朋友最喜欢的辩词——不用它不就是了嘛!
首先如果有这样的C#程序员，我定佩服你如滔滔江水…….但是，我这里要告诉大家的事实是，“即便你程序中确实所有的代码都不使用反射，由于C#/.NET内置地支持反射，那么你也要为此付出性能代价，而且是很高的性能代价”。这是本文的重点，甚至是我后续很多论战文章的重点——很多C#/.NET机制，不管你用不用它，只要内置支持这种机制，就不可避免要付出性能代价(当然如果你要用它，还有更多性能代价)。
好，下面让我们来谈谈为什么，即便不用反射也要付出很高的性能代价
