使用 C++ 中的接口会导致性能损失吗？

Question

在 C++ 中使用接口（抽象基类）时是否存在运行时性能损失？

Answer 1

应该注意的一件事是，虚拟函数调用成本可能因平台而异。 在控制台上，它们可能更明显，因为通常 vtable 调用意味着缓存未命中，并且可能会破坏分支预测。

Answer 2

在 C++ 中使用抽象基类通常要求使用虚函数表，所有接口调用都将通过该表查找。 与原始函数调用相比，成本很小，因此在担心它之前，请确保您需要比这更快。

Answer 3

我所知道的唯一主要区别是，由于您没有使用具体的类，因此内联（更难？）更难做到。

Answer 4

我唯一能想到的是，虚拟方法的调用比非虚拟方法要慢一点，因为调用必须经过 虚拟方法表。

然而，这是一个搞砸你的设计的糟糕理由。 如果您需要更高的性能，请使用更快的服务器。

Answer 5

对于任何包含虚函数的类，都会使用虚函数表。 显然，通过 vtable 等调度机制调用方法比直接调用慢，但在大多数情况下您可以接受。

Answer 6

是的，但据我所知，没有什么值得注意的。 性能下降是因为每个方法调用中都有“间接”。

但是，这实际上取决于您使用的编译器，因为某些编译器无法在从抽象基类继承的类中内联方法调用。

如果您想确定，您应该运行自己的测试。

Answer 7

是的，有处罚。 可以提高平台性能的方法是使用没有虚函数的非抽象类。 然后使用指向非虚函数的成员函数指针。

Answer 8

我知道这是一个不常见的观点，但即使提到这个问题也让我怀疑你对类结构投入了太多的思考。 我见过许多系统有太多的“抽象级别”，仅此一点就使它们容易出现严重的性能问题，不是由于方法调用的成本，而是由于倾向于进行不必要的调用。 如果这种情况发生在多个级别上，那就是致命的。 看一下

Answer 9

大多数人都会注意到运行时间的损失，这是正确的。

然而，根据我从事大型项目的经验，清晰的接口和适当的封装所带来的好处很快就会抵消速度的提升。 模块化代码可以替换为改进的实现，因此最终结果是巨大的收益。

您的情况可能会有所不同，这显然取决于您正在开发的应用程序。

Answer 10

请注意，多重继承会使带有多个 vtable 指针的对象实例变得臃肿。 对于 x86 上的 G++，如果您的类有一个虚方法并且没有基类，那么您就有一个指向 vtable 的指针。 如果你有一个带有虚方法的基类，你仍然有一个指向 vtable 的指针。 如果您有两个带有虚拟方法的基类，则每个实例上都有两个 vtable 指针。

因此，通过多重继承（这就是在 C++ 中实现接口的方式），您需要在对象实例大小中支付基类乘以指针大小。 内存占用的增加可能会间接影响性能。

Answer 11

与常规调用相比，每次虚拟函数调用都会受到较小的惩罚。 除非每秒执行数十万次调用，否则您不太可能观察到差异，而且无论如何，为了提高代码清晰度而付出的代价通常是值得的。

Answer 12

当您调用虚拟函数（例如通过接口）时，程序必须在表中查找该函数，以了解要为该对象调用哪个函数。 与直接调用该函数相比，这会带来较小的损失。

此外，当您使用虚拟函数时，编译器无法内联函数调用。 因此，对某些小函数使用虚函数可能会产生惩罚。 这通常是您可能会看到的最大的性能“打击”。 如果函数很小并且被多次调用（例如在循环内），这实际上只是一个问题。

Answer 13

在某些情况下适用的另一种选择是编译时
与模板的多态性。 例如，当您想要时，它很有用
在计划开始时做出实施选择，以及
然后在执行期间使用它。 一个例子
运行时多态性

class AbstractAlgo
{
    virtual int func();
};

class Algo1 : public AbstractAlgo
{
    virtual int func();
};

class Algo2 : public AbstractAlgo
{
    virtual int func();
};

void compute(AbstractAlgo* algo)
{
      // Use algo many times, paying virtual function cost each time

}   

int main()
{
    int which;
     AbstractAlgo* algo;

    // read which from config file
    if (which == 1)
       algo = new Algo1();
    else
       algo = new Algo2();
    compute(algo);
}

与使用编译时多态性相同

class Algo1
{
    int func();
};

class Algo2
{
    int func();
};


template<class ALGO>  void compute()
{
    ALGO algo;
      // Use algo many times.  No virtual function cost, and func() may be inlined.
}   

int main()
{
    int which;
    // read which from config file
    if (which == 1)
       compute<Algo1>();
    else
       compute<Algo2>();
}

Answer 14

我不认为成本比较是在虚函数调用和直接函数调用之间进行的。 如果您正在考虑使用抽象基类（接口），那么您会遇到这样的情况：您想要根据对象的动态类型执行多个操作之一。 你必须以某种方式做出这样的选择。 一种选择是使用虚函数。 另一种是通过 RTTI（可能昂贵）或向基类添加 type() 方法（可能增加每个对象的内存使用量）来切换对象的类型。 因此，虚函数调用的成本应该与替代方案的成本进行比较，而不是与不执行任何操作的成本进行比较。

Answer 15

使用虚拟分派调用的函数不是内联的

虚拟函数有一种很容易被忘记的惩罚：在编译时不知道对象类型的（常见）情况下，虚拟调用不是内联的。 如果您的函数很小并且适合内联，则这种惩罚可能非常显着，因为您不仅增加了调用开销，而且编译器在优化调用函数方面也受到限制（它必须假设虚函数可能会更改了某些寄存器或内存位置，它无法在调用者和被调用者之间传播常量值）。

虚拟调用成本取决于平台

至于与普通函数调用相比的调用开销损失，答案取决于您的目标平台。 如果您的目标是具有 x86/x64 CPU 的 PC，则调用虚拟函数的损失非常小，因为现代 x86/x64 CPU 可以对间接调用执行分支预测。 但是，如果您的目标是 PowerPC 或其他一些 RISC 平台，则虚拟调用损失可能会相当大，因为在某些平台上永远不会预测间接调用（参见 PC/Xbox 360 跨平台开发最佳实践）。

Answer 16

简短回答： 否。

长回答：
影响速度的并不是基类或类在其层次结构中的祖先数量。 唯一的问题是方法调用的成本。

非虚拟方法调用有成本（但可以内联）
虚拟方法调用的成本稍高，因为您需要在调用之前查找要调用的方法（但这只是简单的表查找而不是搜索）。 由于接口上的所有方法根据定义都是虚拟的，因此存在此成本。

除非您正在编写一些超速度敏感的应用程序，否则这应该不是问题。 使用界面所获得的额外清晰度通常可以弥补任何感知到的速度下降。