这是否有任何令人信服的证明,新的反思不再那么慢,可以使用.有更好的方式来读取属性数据吗？
谢谢,
巴斯卡尔
解决方法
来自ConstructorInfo或MethodInfo的缓存代理可以与任何其他代理进行速度调用.
由ILGenerator.Emit创建的代理(这并不是新的,从版本1开始就在.NET中)同样可以像调用一样快.
通过发出或调用ConstructorInfo的代理获得的对象将与其他任何对象一样快.
如果您通过动态加载程序集来获取对象,使用反射来查找要调用的方法,并调用它,并且实现一个定义的接口,通过该界面从该位置调用它,那么它将如何它被用作该接口的另一个实现.
总而言之,反思给了我们如何做事情,没有它,我们会 – 如果我们可以做到这一点 – 必须使用比代码和执行速度慢的技术.
它也为我们提供了比其他手段更复杂,更脆弱,更不安全,性能更差的东西的手段. C#代码的每一行都可以被使用反射的大块代码所取代.这个代码几乎肯定会比原来的一系列方法差一些,性能是他们中最少的.
相当可能的是,“避免反思,因为它的缓慢”的建议源于这样一种信念,即那种开发人员对于任何新技术来说都是坚果,因为它似乎很酷,将会更有可能被“慢“,而不是”惯用语,更容易出错,难以维护“.很可能这个信念是完全正确的.
在大多数情况下,当最自然和最明显的方法是使用反射时,那么它也不会比要避免它的真正卷曲尝试的性能更差.
如果性能问题适用于反思中的任何事情,那么它真的是隐藏的用途：
只有一点点的工作才能避免使用动态似乎是明智的.这里的性能差异可能值得考虑.
在ASP.NET中,使用<％#DataBinder.Eval(Container.DataItem,“SomeProperty”)％>比<#((SomeType)Container.DataItem)更容易但性能更差.SomeProperty％>或<％#SomeCodeBehindProvidedCallWithTheSameResult％> ;.我仍然会使用前90％的时间,后者只有在我真正关心给定页面的性能或更可能的情况下,因为在同一个对象上执行许多操作会使后者实际上更自然. 所以总而言之,电脑中的一切依然是“缓慢的”,而这些要求在一个宇宙中以消耗能量和耗费时间的方式工作,有一些“缓慢”的价值.不同的反射技术具有不同的成本,但替代方案也是如此.如果将隐藏的反射作为明显的方法,那么其他方法稍微不太明显就可以很好地反映出来. 当然,代码明智地与你使用的任何技术.如果你连续打电话给同一个代表一百次,你应该把它存储起来,而不是每次调用一次,而不管是否通过反思来获取它.
