c# – 反思真的很慢吗？

概述这是一个普遍的信念,反思是缓慢的,尽量避免它.但是,在当前的情况下,这种信念是真的吗？与现有的.net版本有很多变化,比如使用IL Weaving(即IL Emit)等,而不是传统的PropertyInfo和MethodInfo执行反射的方式. 这是否有任何令人信服的证明,新的反思不再那么慢,可以使用.有更好的方式来读取属性数据吗？ 谢谢, 巴斯卡尔 当你想到这件事时,反射是多么令人印象深刻的是多 这是一个普遍的信念,反思是缓慢的,尽量避免它.但是,在当前的情况下,这种信念是真的吗？与现有的.net版本有很多变化,比如使用IL Weaving(即IL Emit)等,而不是传统的PropertyInfo和MethodInfo执行反射的方式.

这是否有任何令人信服的证明,新的反思不再那么慢,可以使用.有更好的方式来读取属性数据吗？

谢谢,
巴斯卡尔

解决方法 当你想到这件事时,反射是多么令人印象深刻的是多快.

来自ConstructorInfo或MethodInfo的缓存代理可以与任何其他代理进行速度调用.

由ILGenerator.Emit创建的代理(这并不是新的,从版本1开始就在.NET中)同样可以像调用一样快.

通过发出或调用ConstructorInfo的代理获得的对象将与其他任何对象一样快.

如果您通过动态加载程序集来获取对象,使用反射来查找要调用的方法,并调用它,并且实现一个定义的接口,通过该界面从该位置调用它,那么它将如何它被用作该接口的另一个实现.

总而言之,反思给了我们如何做事情,没有它,我们会 – 如果我们可以做到这一点 – 必须使用比代码和执行速度慢的技术.

它也为我们提供了比其他手段更复杂,更脆弱,更不安全,性能更差的东西的手段. C#代码的每一行都可以被使用反射的大块代码所取代.这个代码几乎肯定会比原来的一系列方法差一些,性能是他们中最少的.

相当可能的是,“避免反思,因为它的缓慢”的建议源于这样一种信念,即那种开发人员对于任何新技术来说都是坚果,因为它似乎很酷,将会更有可能被“慢“,而不是”惯用语,更容易出错,难以维护“.很可能这个信念是完全正确的.

在大多数情况下,当最自然和最明显的方法是使用反射时,那么它也不会比要避免它的真正卷曲尝试的性能更差.

如果性能问题适用于反思中的任何事情,那么它真的是隐藏的用途：

只有一点点的工作才能避免使用动态似乎是明智的.这里的性能差异可能值得考虑.

在ASP.NET中,使用<％#DataBinder.Eval(Container.DataItem,“SomeProperty”)％>比<#((SomeType)Container.DataItem)更容易但性能更差.someProperty％>或<％#SomeCodeBehindProvIDedCallWithTheSameResult％&gt ;.我仍然会使用前90％的时间,后者只有在我真正关心给定页面的性能或更可能的情况下,因为在同一个对象上执行许多 *** 作会使后者实际上更自然. 所以总而言之,电脑中的一切依然是“缓慢的”,而这些要求在一个宇宙中以消耗能量和耗费时间的方式工作,有一些“缓慢”的价值.不同的反射技术具有不同的成本,但替代方案也是如此.如果将隐藏的反射作为明显的方法,那么其他方法稍微不太明显就可以很好地反映出来. 当然,代码明智地与你使用的任何技术.如果你连续打电话给同一个代表一百次,你应该把它存储起来,而不是每次调用一次,而不管是否通过反思来获取它.

总结

以上是内存溢出为你收集整理的c# – 反思真的很慢吗？全部内容，希望文章能够帮你解决c# – 反思真的很慢吗？所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。