项目刚忙完一个段落，随便在网上逛逛，发现一个对反射的性能分析很激烈的贴子，有很多网友还引用了大量大师的观点，我（狂人）感觉这没什么好讨论的，只不过你们是对问题理解不全面的一个体现。在可配置的框架系统，有些人用了大量的反射而担心系统的性能会不会下降，其实整个系统的性能往往控制在10-20%的代码中，80-90%不管你用什么样的实现，用string、stringbuilder、for或者foreach循环、数组或者集合、以及是否使用反射都是没有任何关系。举个很简单的例子，在一个可配置的框架系统中，我要得到某一个对象的记录并显示在窗口中。一般的过程是，先创建对象的实例—-建立数据库的连接—-传递SQL查询语句—数据库服务器解释并返回满足条件的记录--业务处理层再分析数据—然后显示在窗口中。在这么多处理的环节中，创建该业务对象是不是用反射，以及调用该业务对象是否使用反射对整个数据获取和显示没有任何影响。就这个例子来说，我们应该减少数据在网络中的传输量来提供系统显示的效率。当然也可以通过分页显示、异步处理等欺骗用户视觉的方式来提高效果。但在下面的这个例子中使用反射就不那么聪明了。
foreach (daterow dr in drows)
{
for (int j = 0; j < 100; j++)
{
Type theTest = Type.GetType("MyBusineseObject”);
object theobj = theTest.InvokeMember(null, BindingFlags.CreateInstance
, null, null, null);
}
}
以这个例子来说明反射影响性能而不使用绝对是个错误，首先，我不知道为什么要这样使用，你可以把创建对象放在循环的外部，或者定义一个Interface。或者有可能作者是要根据DataRow的条件来创建对象，如果是这样，那应该把已经创建的对象缓存起来，而不是这样随意创建。其实实现这样的功能很简单，可以增加一个HashTable,把DataRow中创建对象的条件当作Key值，把每个已经创建的对象存储在HashTable中。在每次创建时，先判断该对象是否已经存在，如果已经存在就直接拿来用，如果没有再创建。不管怎么说，这样频繁去创建对象都不是一个很的方法。最好先把你的系统重构一下，也许你的类的设计是有问题的。
一个数据库查询操作比一个反射调用所造成的性能损失高几千倍，在一个数据库应用程序中，反射的性能损失显得微不足道
