C# .NET 反射的代价有多大？

How costly is .NET reflection?

提问by Dan Herbert

I constantly hear how bad reflection is to use. While I generally avoid reflection and rarely find situations where it is impossible to solve my problem without it, I was wondering...

我不断听到使用反射是多么糟糕。虽然我通常会避免反思并且很少发现没有它就无法解决我的问题的情况，但我想知道......

For those who have used reflection in applications, have you measured performance hits and, is it really so bad?

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

采纳答案by Martin Marconcini

It is. But that depends on what you're trying to do.

这是。但这取决于您要尝试做什么。

I use reflection to dynamically load assemblies (plugins) and its performance "penalty" is not a problem, since the operation is something I do during startup of the application.

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

However, if you're reflecting inside a series of nested loops with reflection calls on each, I'd say you should revisit your code :)

但是，如果您在一系列嵌套循环中进行反射，每个循环都有反射调用，我会说您应该重新访问您的代码:)

For "a couple of time" operations, reflection is perfectly acceptable and you won't notice any delay or problem with it. It's a very powerful mechanism and it is even used by .NET, so I don't see why you shouldn't give it a try.

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

回答by lomaxx

As with everything, it's all about assessing the situation. In DotNetNukethere's a fairly core component called FillObjectthat uses reflection to populate objects from datarows.

与所有事情一样，一切都与评估情况有关。在DotNetNuke 中有一个相当核心的组件，称为FillObject使用反射从数据行填充对象。

This is a fairly common scenario and there's an article on MSDN, Using Reflection to Bind Business Objects to ASP.NET Form Controlsthat covers the performance issues.

这是一个相当常见的场景，MSDN 上有一篇文章使用反射将业务对象绑定到 ASP.NET 表单控件，其中涵盖了性能问题。

Performance aside, one thing I don't like about using reflection in that particular scenario is that it tends to reduce the ability to understand the code at a quick glance which for me doesn't seem worth the effort when you consider you also lose compile time safety as opposed to strongly typed datasets or something like LINQ to SQL.

除了性能之外，我不喜欢在那个特定场景中使用反射的一件事是它往往会降低快速浏览代码的能力，当你认为你也失去了编译时，这对我来说似乎不值得付出努力时间安全，而不是强类型数据集或类似LINQ to SQL 的东西。

回答by aku

Reflection can have noticeable impact on performance if you use it for frequent object creation. I've developed application based on Composite UI Application Blockwhich is relying on reflection heavily. There was a noticeable performance degradation related with objects creation via reflection.

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

However in most cases there are no problems with reflection usage. If your only need is to inspect some assembly I would recommend Mono.Cecilwhich is very lightweight and fast

然而，在大多数情况下，反射使用没有问题。如果您只需要检查一些组件，我会推荐Mono.Cecil，它非常轻巧且快速

回答by Mike Thompson

As with all things in programming you have to balance performance cost with with any benefit gained. Reflection is an invaluable tool when used with care. I created a O/R mapping library in C# which used reflection to do the bindings. This worked fantastically well. Most of the reflection code was only executed once, so any performance hit was quite small, but the benefits were great. If I were writing a new fandangled sorting algorithm, I would probably not use reflection, since it would probably scale poorly.

与编程中的所有事情一样，您必须在性能成本与获得的任何好处之间取得平衡。小心使用时，反射是一种非常宝贵的工具。我在 C# 中创建了一个 O/R 映射库，它使用反射来进行绑定。这非常有效。大多数反射代码只执行一次，因此任何性能损失都非常小，但好处是巨大的。如果我正在编写一个新的 fandangled 排序算法，我可能不会使用反射，因为它可能扩展性很差。

I appreciate that I haven't exactly answered your question here. My point is that it doesn't really matter. Use reflection where appropriate. It's just another language feature that you need to learn how and when to use.

我很感激我在这里没有完全回答你的问题。我的观点是这并不重要。在适当的地方使用反射。这只是您需要了解如何以及何时使用的另一种语言功能。

回答by ESRogs

In his talk The Performance of Everyday Things, Jeff Richter shows that calling a method by reflection is about 1000 times slowerthan calling it normally.

在他的演讲The Performance of Everyday Things 中，Jeff Richter 表明通过反射调用方法比正常调用方法慢 1000 倍。

Jeff's tip: if you need to call the method multiple times, use reflection once to find it, then assign it to a delegate, and then call the delegate.

Jeff 的提示：如果需要多次调用该方法，使用一次反射找到它，然后将其分配给一个委托，然后调用该委托。

回答by McKenzieG1

It's bad enough that you have to be worried even about reflection done internally by the .NET libraries for performance-critical code.

这已经够糟糕了，您甚至不得不担心 .NET 库在内部为性能关键代码完成的反射。

The following example is obsolete - true at the time (2008), but long ago fixed in more recent CLR versions. Reflection in general is still a somewhat costly thing, though!

以下示例已过时 - 当时（2008 年）为真，但很久以前已在更新的 CLR 版本中修复。不过，一般来说，反射仍然是一件代价高昂的事情！

Case in point: You should never use a member declared as "Object" in a lock (C#) / SyncLock (VB.NET) statement in high-performance code. Why? Because the CLR can't lock on a value type, which means that it has to do a run-time reflection type check to see whether or not your Object is actually a value type instead of a reference type.

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

回答by Gaz

My most pertinent experience was writing code to compare any two data entities of the same type in a large object model property-wise. Got it working, tried it, ran like a dog, obviously.

我最相关的经验是编写代码来比较大型对象模型中相同类型的任何两个数据实体的属性。很明显，让它工作，尝试过，像狗一样奔跑。

I was despondent, then overnight realised that wihout changing the logic, I could use the same algorithm to auto-generate methods for doing the comparison but statically accessing the properties. It took no time at all to adapt the code for this purpose and I had the ability to do deep property-wise comparison of entities with static code that could be updated at the click of a button whenever the object model changed.

我很沮丧，然后一夜之间意识到无需更改逻辑，我可以使用相同的算法自动生成方法来进行比较，但静态访问属性。完全没有时间为此目的调整代码，我有能力对实体与静态代码进行深入的属性比较，只要对象模型发生变化，只需单击按钮即可更新。

My point being: In conversations with colleagues since I have several times pointed out that their use of reflection could be to autogenerate code to compile rather than perform runtime operations and this is often worth considering.

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

回答by Quibblesome

Not massively. I've never had an issue with it in desktop development unless, as Martin states, you're using it in a silly location. I've heard a lot of people have utterly irrational fears about its performance in desktop development.

不是大规模。我在桌面开发中从来没有遇到过它的问题，除非正如 Martin 所说，你在一个愚蠢的地方使用它。我听说很多人对它在桌面开发中的表现有完全不合理的担忧。

In the Compact Framework(which I'm usually in) though, it's pretty much anathemaand should be avoided like the plague in most cases. I can still get away with using it infrequently, but I have to be really careful with its application which is way less fun. :(

但是，在Compact Framework（我通常使用的框架）中，它几乎是令人厌恶的，并且在大多数情况下应该像瘟疫一样避免。我仍然可以不经常使用它，但我必须非常小心它的应用程序，这不太有趣。:(

回答by Chris Pietschmann

Reflection does not drastically slow the performance of your app. You may be able to do certain things quicker by not using reflection, but if Reflection is the easiest way to achieve some functionality, then use it. You can always refactor you code away from Reflection if it becomes a perf problem.

反射不会显着降低应用程序的性能。通过不使用反射，您可能能够更快地完成某些事情，但是如果反射是实现某些功能的最简单方法，那么请使用它。如果它成为性能问题，您总是可以重构您的代码，使其远离反射。

回答by tsimon

I think you will find that the answer is, it depends. It's not a big deal if you want to put it in your task-list application. It is a big deal if you want to put it in Facebook's persistence library.

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