静态方法与实例方法的性能 [英] Performance of static methods vs instance methods

问题描述

我的问题与静态方法与实例方法的性能特征及其可扩展性有关.假设对于这种情况，所有类定义都在一个程序集中，并且需要多个离散的指针类型.

My question is relating to the performance characteristics of static methods vs instance methods and their scalability. Assume for this scenario that all class definitions are in a single assembly and that multiple discrete pointer types are required.

考虑:

public sealed class InstanceClass
{
      public int DoOperation1(string input)
      {
          // Some operation.
      }

      public int DoOperation2(string input)
      {
          // Some operation.
      }

      // … more instance methods.
}

public static class StaticClass
{
      public static int DoOperation1(string input)
      {
          // Some operation.
      }

      public static int DoOperation2(string input)
      {
          // Some operation.
      }

      // … more static methods.
}

上面的类代表一个辅助样式模式.

The above classes represent a helper style pattern.

在一个实例类中，解析实例方法需要一些时间来做，而不是静态类.

In an instance class, resolving the instance method take a moment to do as oppose to StaticClass.

我的问题是:

1. 当保持状态不是问题(不需要字段或属性)时，使用静态类总是更好吗?

1. When keeping state is not a concern (no fields or properties are required), is it always better to use a static class?

如果有相当数量的这些静态类定义(例如 100 个，每个静态方法有多个)，与相同数量的实例类定义相比，这是否会对执行性能或内存消耗产生负面影响?

Where there is a considerable number of these static class definitions (say 100 for example, with a number of static methods each) will this affect execution performance or memory consumption negatively as compared with the same number of instance class definitions?

调用同一个实例类中的另一个方法时，是否还会出现实例解析?例如，在同一实例的 DoOperation1 中使用像 this.DoOperation2("abc") 这样的 [this] 关键字.

When another method within the same instance class is called, does the instance resolution still occur? For example using the [this] keyword like this.DoOperation2("abc") from within DoOperation1 of the same instance.

推荐答案

理论上，静态方法的性能应该比实例方法稍好一些，其他条件相同，因为额外的隐藏 this 参数.

In theory, a static method should perform slightly better than an instance method, all other things being equal, because of the extra hidden this parameter.

在实践中，这几乎没有什么区别，以至于它会隐藏在各种编译器决策的噪音中.(因此，两个人可以证明"一个比另一个更好的结果不一致).尤其是因为 this 通常在寄存器中传递，并且通常以该寄存器开头.

In practice, this makes so little difference that it'll be hidden in the noise of various compiler decisions. (Hence two people could "prove" one better than the other with disagreeing results). Not least since the this is normally passed in a register and is often in that register to begin with.

最后一点意味着，理论上，我们应该期待一个静态方法，它接受一个对象作为参数并用它做一些事情，比作为同一个对象上的实例的等效方法稍差.尽管如此，差异是如此微小，以至于如果您试图衡量它，您最终可能会衡量其他一些编译器决策.(特别是因为该引用始终在寄存器中的可能性也很高).

This last point means that in theory, we should expect a static method that takes an object as a parameter and does something with it to be slightly less good than the equivalent as an instance on that same object. Again though, the difference is so slight that if you tried to measure it you'd probably end up measuring some other compiler decision. (Especially since the likelihood if that reference being in a register the whole time is quite high too).

真正的性能差异将归结为您是否人为地将对象放在内存中来做一些自然应该是静态的事情，或者您是否正在以复杂的方式纠缠对象传递链来做自然应该是实例的事​​情.

The real performance differences will come down to whether you've artificially got objects in memory to do something that should naturally be static, or you're tangling up chains of object-passing in complicated ways to do what should naturally be instance.

因此对于第 1 点.当保持状态不是问题时，静态总是更好，因为这就是静态的目的.这不是一个性能问题，尽管有一个很好地使用编译器优化的总体规则 - 更有可能有人会努力优化正常使用的案例，而不是那些奇怪使用的案例.

Hence for number 1. When keeping state isn't a concern, it's always better to be static, because that's what static is for. It's not a performance concern, though there is an overall rule of playing nicely with compiler optimisations - it's more likely that someone went to the effort of optimising cases that come up with normal use than those which come up with strange use.

数字 2.没有区别.每个成员都有一定数量的每类成本，这包括有多少元数据、实际 DLL 或 EXE 文件中有多少代码，以及有多少 jitted 代码.无论是实例还是静态都是一样的.

Number 2. Makes no difference. There's a certain amount of per-class cost for each member it terms of both how much metadata there is, how much code there is in the actual DLL or EXE file, and how much jitted code there'll be. This is the same whether it's instance or static.

对于第 3 项，this 和 this 一样.但是请注意:

With item 3, this is as this does. However note:

1. this 参数在特定寄存器中传递.当在同一个类中调用一个实例方法时，它可能已经在那个寄存器中(除非它被隐藏起来并且由于某种原因使用了该寄存器)，因此不需要设置 this它需要设置为什么.这在一定程度上适用于例如方法的前两个参数是调用的前两个参数.

1. The this parameter is passed in a particular register. When calling an instance method within the same class, it'll likely be in that register already (unless it was stashed and the register used for some reason) and hence there is no action required to set the this to what it needs to be set to. This applies to a certain extent to e.g. the first two parameters to the method being the first two parameters of a call it makes.

由于很明显 this 不为 null，因此在某些情况下可用于优化调用.

Since it'll be clear that this isn't null, this may be used to optimise calls in some cases.

由于很明显 this 不为 null，这可能会使内联方法调用再次变得更高效，因为为伪造方法调用而生成的代码可以省略一些 null-无论如何检查它可能需要.

Since it'll be clear that this isn't null, this may make inlined method calls more efficient again, as the code produced to fake the method call can omit some null-checks it might need anyway.

也就是说，空检查很便宜！

That said, null checks are cheap!

值得注意的是，作用于对象的通用静态方法，而不是实例方法，可以减少在 http://joeduffyblog.com/2011/10/23/on-generics-and-some-of-the-related-overheads/ 在没有为给定类型调用给定静态的情况下.正如他所说:顺便说一句，事实证明，扩展方法是使泛型抽象更具性价比的好方法."

It is worth noting that generic static methods acting on an object, rather than instance methods, can reduce some of the costs discussed at http://joeduffyblog.com/2011/10/23/on-generics-and-some-of-the-associated-overheads/ in the case where that given static isn't called for a given type. As he puts it "As an aside, it turns out that extension methods are a great way to make generic abstractions more pay-for-play."

但是，请注意，这仅与方法使用的其他类型的实例化有关，否则不存在.因此，它确实不适用于很多情况(其他一些实例方法使用了该类型，其他地方的一些其他代码使用了该类型).

However, note that this relates only to the instantiation of other types used by the method, that don't otherwise exist. As such, it really doesn't apply to a lot of cases (some other instance method used that type, some other code somewhere else used that type).

总结:

1. 大多数情况下，实例与静态的性能成本低于可以忽略不计.
2. 例如，您滥用静态通常会产生什么成本，反之亦然.如果您不在静态和实例之间做出决定，那么您更有可能得到正确的结果.
3. 在极少数情况下，另一种类型中的静态泛型方法导致创建的类型少于实例泛型方法，这可以使其有时变得很少使用(并且很少" 指的是它在应用程序的生命周期中使用的类型，而不是它被调用的频率).一旦你明白了他在那篇文章中所说的内容，你就会发现它与大多数静态与实例决策 100% 无关.它主要只有 ngen 的成本，而不是 jitted 代码.

1. Mostly the performance costs of instance vs static are below negligible.
2. What costs there are will generally come where you abuse static for instance or vice-versa. If you don't make it part of your decision between static and instance, you are more likely to get the correct result.
3. There are rare cases where static generic methods in another type result in fewer types being created, than instance generic methods, that can make it sometimes have a small benefit to turn rarely used (and "rarely" refers to which types it's used with in the lifetime of the application, not how often it's called). Once you get what he's talking about in that article you'll see that it's 100% irrelevant to most static-vs-instance decisions anyway. And it mostly only has that cost with ngen, not with jitted code.

关于空检查有多便宜的注释(我在上面声称)..NET 中的大多数空检查根本不检查空值，而是继续他们要做的事情，假设它会工作，如果发生访问异常，它会变成 NullReferenceException.因此，主要是当 C# 代码在概念上涉及空检查时，因为它正在访问一个实例成员，如果它成功，成本实际上为零.一个例外是一些内联调用，(因为他们想要表现得好像他们调用了一个实例成员)并且他们只是点击了一个字段来触发相同的行为，所以他们也非常便宜，而且他们仍然经常被排除在外(例如，如果该方法的第一步涉及访问原样的字段).

A note on just how cheap null-checks are (which I claimed above). Most null-checks in .NET don't check for null at all, rather they continue what they were going to do with the assumption that it'll work, and if a access exception happens it gets turned into a NullReferenceException. As such, mostly when conceptually the C# code involves a null-check because it's accessing an instance member, the cost if it succeeds is actually zero. An exception would be some inlined calls, (because they want to behave as if they called an instance member) and they just hit a field to trigger the same behaviour, so they are also very cheap, and they can still often be left out anyway (e.g. if the first step in the method involved accessing a field as it was).

这篇关于静态方法与实例方法的性能的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！