有没有人对reflection == bad performance普遍接受的口头禅有一个很好的解释？
例如，与直接访问所有属性相比，迭代类型的属性集合并从此类型的实例中提取所有属性值有多昂贵？一个等级？二？它取决于什么？它可以预测吗？引擎盖下发生了什么？
编辑：感谢您的回答。我已经研究了你提供的一些链接，似乎与直接访问相比，有关物业反思的估计差距很大：从慢2.5倍到慢200倍。
这对我来说似乎不太合理。有些人提到了.Net的更高版本中的性能改进，所以让我的问题缩小到.Net 4.0。有人有任何基准吗？
答案 0 :(得分：12)
最好的答案是，普遍接受的口头禅并不像看起来那么简单。 reflection == bad performance主要源自.NET 1.0和1.1，并且未能确认更高版本中的性能改进。
为了客观，我已经在很多场合测试了基于反射的解决方案与基于非反射的解决方案 - 并且获胜者并不总是一个或另一个。反思就是这样，它的工作原理是它的工作方式，它不是更快或更慢，它（基本上所有的编程方法）都不能被视为银弹或永远被避免的东西。
答案 1 :(得分：3)
谁在乎别人怎么想？如果您对选项进行了有根据的调查（包括其他不需要您正在调查的技术的方法），并发现它是正确的选项，那么请使用它。
http://www.parashift.com/c++-faq-lite/big-picture.html#faq-6.16
至于“引擎盖下发生的事情”，你似乎有部分照片。还有一个事实是，没有任何链接是硬编码的，所有这些都必须在运行时查找。这意味着没有内嵌是可能的，如果您错误输入成员名称，则不会创建编译器错误，并且必须使用字符串查找所有成员，并且任何关联的字符串比较perf命中（可能存在也可能不存在，具体取决于内容比如字符串实习等。）
修改
嗯，我想我答案的最后一部分不一定正确。它在很大程度上取决于你如何使用反射。轮廓！如果你想出一个替代解决方案，那也是如此。 ：）
答案 2 :(得分：3)
有几个问题可以通过各种方式解决这个问题。
这是一个很好的IMO：What is the "cost" of .NET reflection?
其中一个articles the answerer links提供了一些关于某些反射函数的有趣信息，这些函数比其他函数更昂贵。例如，做一个typeof并不是太糟糕，但调用方法的成本更高。
答案 3 :(得分：3)
有些事情你不能静态地做。在需要时使用反射。你可能已经比你意识到的更多地使用它了。
我为反射与静态操作做了很多性能测试和测量。反思有更多的工作要做，而且总是比较慢。但那没关系。 “较慢”并不意味着“慢”，它只是意味着“不那么快”。这是应该如何考虑的。反射仍然很快，不像静态操作那么快。因此，不应该自动避开它。
我曾为那些绝对禁止在Web项目中使用任何反射代码的首席开发人员工作，因为它会很慢。但是他似乎从未想过我们使用的是NHibernate，ASP.NET和ASP.NET MVC数据绑定，所有这些都只能用于反射数据绑定。
那个人对反思的厌恶是不合理的，毫无根据的。我认为很多人都是这样谈论的。
答案 4 :(得分：2)
关于反思存在很多误解。
This guy表明反射大约比直接分配长3倍。实际上，正确使用此功能不会对性能产生明显影响。在正确的上下文中使用反射没有任何问题。