接口和工厂引入的间接如何影响性能？

Question

我想提高一些遗留代码的可测试性。为了实现这一点，我将介绍现有类的接口（并且现有类实现这些接口）和工厂，它们创建测试对象的实例或原始类的对象，具体取决于某些配置设置。

我可以预见到一些内部反馈'但这会影响性能'，但我希望能够测试一些代码（在这种情况下为服务层），而不必部署所有底层和设置数据库服务器。

您是否有任何介绍间接引起的性能明显影响性能的经验？什么是回应上述反馈的建设性方式？

谢谢，

Martijn

Answer 1

根据Don Box（Essential .NET第1卷）的一本书，与在类上调用函数相比，在接口上调用函数的效果是一条机器指令，因为还有一个间接。这意味着在2 GHz处理器上，调用接口方法比使用类方法慢0.0000000005秒。

这是指.net版本1实现（我有本书的旧版本）。我不确定这对于较新的版本是否会发生很大变化，或者它如何适用于Mono，但我绝对不会认为会产生戏剧效果。

正如您所看到的，在现代计算机上，效果应该是可以忽略的，除非在极少数情况下您必须每纳秒寻找一次。

Answer 2

简短的回答：它根本没有任何区别。

答案越长：几乎可以肯定没有任何区别。唯一真正的性能差异应该是通过接口的方法调用无法内联，因此在原始类中内联的任何方法都会因接口而变慢。但是，我们每次通话只会说几个纳秒，所以如果你在课堂上有内联方法，如果它们被调用了数百万次，那么你可能会看到明显的差异。但是，如果你有这样一个方法，这是你的应用程序的性能的限制因素，那么性能迷们肯定已经测量过并且能够告诉你。不是吗？

Answer 3

接口方法调用的唯一区别是保证是虚方法调用。它在直接类实例方法调用中是可选的，具体取决于您是否将其声明为虚拟。

在实践中没有区别，VB.NET编译器使用与C＃编译器相同的技巧。即使该方法不是虚拟的，它也会进行间接调用，对其隐式空引用检查很有用。只有静态方法调用可能会更便宜。

担心这一点毫无意义。