我经常听说使用反射是多么糟糕。虽然我通常避免反思,也很少发现不反思就无法解决问题的情况,但我在想……

对于那些在应用程序中使用反射的人,您测量过性能影响吗?它真的那么糟糕吗?


当前回答

如果将反射用于频繁创建对象,则它会对性能产生显著影响。我开发了一个基于复合UI应用程序块的应用程序,它严重依赖反射。通过反射创建对象时,有明显的性能下降。

但是在大多数情况下,使用反射是没有问题的。如果你只需要检查一些组装,我会推荐Mono。塞西尔,非常轻,速度很快

其他回答

它是。但这取决于你要做什么。

我使用反射动态加载程序集(插件),它的性能“惩罚”不是问题,因为操作是我在应用程序启动期间所做的事情。

然而,如果你在一系列嵌套循环中反射,每个循环都有反射调用,我想说你应该重新审视你的代码:)

对于“几次”操作,反射是完全可以接受的,您不会注意到任何延迟或问题。它是一种非常强大的机制,甚至被。net使用,所以我不明白为什么你不应该尝试一下。

我最相关的经验是编写代码来比较大型对象模型中相同类型的任何两个数据实体的属性。把它修好,试了试,显然跑得像条狗。

我很沮丧,然后在一夜之间意识到,在不改变逻辑的情况下,我可以使用相同的算法自动生成方法来进行比较,但静态地访问属性。为了这个目的调整代码完全不花时间,而且我有能力对实体与静态代码进行深入的属性比较,每当对象模型发生变化时,只要单击按钮就可以更新静态代码。

我的观点是:在与同事的对话中,因为我已经多次指出他们使用反射可以自动生成代码来编译,而不是执行运行时操作,这通常值得考虑。

不严重。我从来没有在桌面开发中遇到过问题,除非,正如Martin所说,你在一个愚蠢的位置使用它。我听说很多人对它在桌面开发中的表现有完全不合理的担忧。

然而,在紧凑框架(我经常参与)中,它几乎是一种诅咒,在大多数情况下应该像瘟疫一样避免。我仍然可以不经常使用它,但我必须非常小心地使用它,这就不那么有趣了。:(

您甚至不得不担心. net库内部为性能关键型代码所做的反射,这已经够糟糕的了。

下面的例子在当时(2008年)是过时的,但在最近的CLR版本中早就修复了。不过,总的来说,反思仍然是一件有点昂贵的事情!

举个例子:在高性能代码中,永远不要在lock (c#) / SyncLock (VB.NET)语句中使用声明为“Object”的成员。为什么?因为CLR不能锁定值类型,这意味着它必须执行运行时反射类型检查,以查看您的对象是否实际上是值类型而不是引用类型。

我想你会发现答案是,这要看情况。如果您想把它放在任务列表应用程序中,这不是什么大问题。如果你想把它放在Facebook的持久性库中,这是一件大事。