在C ++类中使用虚拟方法的性能成本是多少？

C ++类（或其任何父类）中至少有一个虚拟方法意味着该类将具有一个虚拟表，并且每个实例将具有一个虚拟指针。

因此，内存成本非常明显。最重要的是实例上的内存开销（特别是如果实例很小，例如，如果它们仅打算包含一个整数：在这种情况下，每个实例中都有一个虚拟指针可能会使实例的大小增加一倍。）虚拟表所用的内存空间，我想它与实际方法代码所用的空间相比通常可以忽略不计。

这让我想到了一个问题：将方法虚拟化是否有可衡量的性能成本（即速度影响）？在每次调用方法时，都会在运行时在虚拟表中进行查找，因此，如果对这个方法的调用非常频繁，并且如果此方法很短，那么性能可能会受到影响吗？我猜这取决于平台，但是有人在运行一些基准测试吗？

我问的原因是，我遇到了一个错误，该错误恰好是由于程序员忘记定义虚拟方法而引起的。这不是我第一次看到这种错误。我想：我们为什么要添加虚拟关键字，而不是需要时取出时，我们绝对相信这是它的虚拟关键字没有必要？如果性能成本很低，我想我会在团队中简单推荐以下内容：只需在每个类中默认使每个方法都是虚拟的，包括析构函数，并且仅在需要时才将其删除。这听起来对您来说疯狂吗？

我在 3GHz顺序PowerPC处理器上运行了一些计时。在该架构上，虚拟函数调用比直接（非虚拟）函数调用花费7纳秒的时间。

因此，除非该函数像一个普通的Get（）/ Set（）访问器之类，否则其中的开销真的不值得担心，在该访问器中，除了内联之外的任何东西都是浪费的。内联到0.5ns的函数的7ns开销很严重；一个需要500毫秒执行的函数的7 ns开销是没有意义的。

虚拟函数的巨大代价实际上并不是在vtable中查找函数指针（通常只是一个周期），而是间接跳转通常无法分支预测。这可能会导致较大的流水线气泡，因为处理器无法提取任何指令，直到间接跳转（通过函数指针的调用）已退出并计算出新的指令指针为止。因此，虚拟函数调用的成本要比看汇编看起来要大得多……但是仍然只有7纳秒。

编辑：安德鲁，不确定，其他人也提出了一个很好的观点，即虚函数调用可能会导致指令高速缓存未命中：如果您跳转到不在高速缓存中的代码地址，则整个程序将陷入死机状态。指令从主存储器中取出。这始终是一个严重的停顿：在氙气灯上，大约有650个循环（根据我的测试）。

但这不是虚拟函数特有的问题，因为如果您跳转到不在缓存中的指令，那么即使直接调用函数也会导致未命中。重要的是该函数是否最近才运行过（使它更有可能在缓存中运行），以及您的体系结构是否可以预测静态（而非虚拟）分支并将这些指令提前提取到缓存中。我的PPC没有，但也许是Intel最新的硬件。

我的计时控制用于控制icache丢失对执行的影响（故意，因为我试图隔离检查CPU管道），因此它们降低了该成本。

调用虚拟函数时，绝对有可衡量的开销-调用必须使用vtable解析该类型对象的函数地址。额外的说明是您最少的担心。vtable不仅会阻止许多潜在的编译器优化（由于类型是编译器的多态性），它们还会破坏I-Cache。

当然，这些惩罚是否重要取决于您的应用程序，执行这些代码路径的频率以及您的继承模式。

但是我认为，默认情况下将所有内容虚拟化是可以用其他方式解决的问题的全面解决方案。

也许您可以看看类的设计/记录/编写方式。通常，类的标头应明确说明派生类可以覆盖哪些函数以及如何调用它们。让程序员编写此文档有助于确保正确地将其标记为虚拟。

我还要说，将每个函数都声明为虚拟函数可能会导致更多的错误，而不仅仅是忘记将某些函数标记为虚拟函数。如果所有功能都是虚拟的，则所有内容都可以用基类（公共，受保护，私有）代替-一切都变得公平。然后，偶然或有意的子类可能会更改功能的行为，从而在基础实现中使用时会引起问题。

这取决于。:)（您还有其他期望吗？）

一旦一个类获得了一个虚函数，它就不能再成为POD数据类型（也可能不是以前的POD数据类型，在这种情况下不会有什么不同），这使得不可能进行全部优化。

纯POD类型上的std :: copy（）可以求助于简单的memcpy例程，但是非POD类型必须更谨慎地处理。

由于必须初始化vtable，因此构建速度会慢很多。在最坏的情况下，POD和非POD数据类型之间的性能差异可能会很大。

在最坏的情况下，您可能会看到执行速度降低了5倍（该数字来自我最近为重新实现一些标准库类而做的一个大学项目。构建容器时，只要存储的数据类型达到vtable）

当然，在大多数情况下，您不太可能看到任何可衡量的性能差异，这只是要指出，在某些边界情况下，这样做可能会付出高昂的代价。

但是，性能不是这里的主要考虑因素。由于其他原因，使所有内容虚拟化不是一个完美的解决方案。

允许在派生类中覆盖所有内容，这使得维护类不变式变得更加困难。当可以随时重新定义其任何一种方法时，如何保证类保持一致状态？

将所有内容虚拟化可能会消除一些潜在的错误，但同时也会引入新的错误。

如果您需要虚拟调度功能，则必须付出代价。C ++的优点是您可以使用编译器提供的非常高效的虚拟调度实现，而不是您自己实现的效率低下的版本。

但是，如果您不需要的话，就用开销来烦恼自己，这可能会太过分了。而且大多数类都不是要继承的-创建良好的基类不仅需要将其功能虚拟化。

虚拟调度比某些替代方案要慢一个数量级-并不是由于间接，而是因为防止了内联。下面，我通过将虚拟调度与在对象中嵌入“类型（标识）号”的实现进行对比，并使用switch语句选择特定于类型的代码，以进行说明。这样可以完全避免函数调用的开销-只需执行局部跳转即可。通过特定类型功能的强制本地化（在交换机中），在维护性，重新编译依赖性等方面存在潜在成本。

实施方式

#include <iostream>
#include <vector>

// virtual dispatch model...

struct Base
{
    virtual int f() const { return 1; }
};

struct Derived : Base
{
    virtual int f() const { return 2; }
};

// alternative: member variable encodes runtime type...

struct Type
{
    Type(int type) : type_(type) { }
    int type_;
};

struct A : Type
{
    A() : Type(1) { }
    int f() const { return 1; }
};

struct B : Type
{
    B() : Type(2) { }
    int f() const { return 2; }
};

struct Timer
{
    Timer() { clock_gettime(CLOCK_MONOTONIC, &from); }
    struct timespec from;
    double elapsed() const
    {
        struct timespec to;
        clock_gettime(CLOCK_MONOTONIC, &to);
        return to.tv_sec - from.tv_sec + 1E-9 * (to.tv_nsec - from.tv_nsec);
    }
};

int main(int argc)
{
  for (int j = 0; j < 3; ++j)
  {
    typedef std::vector<Base*> V;
    V v;

    for (int i = 0; i < 1000; ++i)
        v.push_back(i % 2 ? new Base : (Base*)new Derived);

    int total = 0;

    Timer tv;

    for (int i = 0; i < 100000; ++i)
        for (V::const_iterator i = v.begin(); i != v.end(); ++i)
            total += (*i)->f();

    double tve = tv.elapsed();

    std::cout << "virtual dispatch: " << total << ' ' << tve << '\n';

    // ----------------------------

    typedef std::vector<Type*> W;
    W w;

    for (int i = 0; i < 1000; ++i)
        w.push_back(i % 2 ? (Type*)new A : (Type*)new B);

    total = 0;

    Timer tw;

    for (int i = 0; i < 100000; ++i)
        for (W::const_iterator i = w.begin(); i != w.end(); ++i)
        {
            if ((*i)->type_ == 1)
                total += ((A*)(*i))->f();
            else
                total += ((B*)(*i))->f();
        }

    double twe = tw.elapsed();

    std::cout << "switched: " << total << ' ' << twe << '\n';

    // ----------------------------

    total = 0;

    Timer tw2;

    for (int i = 0; i < 100000; ++i)
        for (W::const_iterator i = w.begin(); i != w.end(); ++i)
            total += (*i)->type_;

    double tw2e = tw2.elapsed();

    std::cout << "overheads: " << total << ' ' << tw2e << '\n';
  }
}

性能结果

在我的Linux系统上：

~/dev  g++ -O2 -o vdt vdt.cc -lrt
~/dev  ./vdt                     
virtual dispatch: 150000000 1.28025
switched: 150000000 0.344314
overhead: 150000000 0.229018
virtual dispatch: 150000000 1.285
switched: 150000000 0.345367
overhead: 150000000 0.231051
virtual dispatch: 150000000 1.28969
switched: 150000000 0.345876
overhead: 150000000 0.230726

这表明内联类型-数字切换方法的速度大约是（1.28-0.23）/（0.344-0.23）= 9.2倍。当然，这是特定于经过测试的确切系统/编译器标志和版本等，但通常是指示性的。

关于虚拟发货的评论

必须指出的是，虚函数调用的开销很少会变得很重要，而且仅对于通常称为琐碎的函数（如getter和setter）而言。即使这样，您也可以提供一个功能来一次获取并设置很多东西，从而将成本降到最低。人们过分担心虚拟派遣方式-在发现笨拙的替代方案之前要进行概要分析。它们的主要问题是它们执行了离线函数调用，尽管它们还对执行的代码进行了非本地化，从而改变了缓存利用率模式（更好或更（通常）更糟）。

在大多数情况下，额外的成本几乎没有。（原谅双关语）。ejac已经发布了明智的相关措施。

您放弃的最大事情是由于内联而可能进行的优化。如果使用常量参数调用函数，它们可能会特别好。这很少能带来真正的改变，但是在少数情况下，这可能是巨大的。

关于优化：
重要的是要了解并考虑语言构造的相对成本。大O表示法只是故事的一半- 您的应用程序如何扩展。另一半是前面的常数。

根据经验，除非有明确而明确的迹象表明它是瓶颈，否则我不会竭力避免使用虚函数。干净的设计永远是第一位的-但只有一个利益相关者不应该过分伤害他人。

人为的例子：一百万个小元素阵列上的空虚拟析构函数可能会翻阅至少4MB的数据，从而破坏您的缓存。如果可以内联该析构函数，则不会触及数据。

在编写库代码时，这些考虑还为时过早。您永远不知道函数周围会出现多少个循环。

尽管其他人对虚拟方法的性能都是正确的，但我认为真正的问题是团队是否了解C ++中虚拟关键字的定义。

考虑这段代码，输出是什么？

#include <stdio.h>

class A
{
public:
    void Foo()
    {
        printf("A::Foo()\n");
    }
};

class B : public A
{
public:
    void Foo()
    {
        printf("B::Foo()\n");
    }
};

int main(int argc, char** argv)
{    
    A* a = new A();
    a->Foo();

    B* b = new B();
    b->Foo();

    A* a2 = new B();
    a2->Foo();

    return 0;
}

这里不足为奇：

A::Foo()
B::Foo()
A::Foo()

由于没有什么是虚拟的。如果在A和B类中都将virtual关键字添加到Foo的前面，我们将得到以下结果：

A::Foo()
B::Foo()
B::Foo()

几乎每个人都期望的。

现在，您提到存在错误，因为有人忘记添加虚拟关键字。因此，请考虑以下代码（将virtual关键字添加到A，但不添加到B类）。那么输出是什么？

#include <stdio.h>

class A
{
public:
    virtual void Foo()
    {
        printf("A::Foo()\n");
    }
};

class B : public A
{
public:
    void Foo()
    {
        printf("B::Foo()\n");
    }
};

int main(int argc, char** argv)
{    
    A* a = new A();
    a->Foo();

    B* b = new B();
    b->Foo();

    A* a2 = new B();
    a2->Foo();

    return 0;
}

答：就像将虚拟关键字添加到B一样？原因是B :: Foo的签名与A :: Foo（）完全匹配，并且由于A的Foo是虚拟的，因此B的也是。

现在考虑B的Foo是虚拟的而A的不是虚拟的情况。那么输出是什么？在这种情况下，输出为

A::Foo()
B::Foo()
A::Foo()

virtual关键字在层次结构中向下而不是向上。它永远不会使基类方法成为虚拟方法。多态性是何时开始在层次结构中首次遇到虚拟方法的。以后的类无法使先前的类具有虚拟方法。

不要忘记，虚方法意味着该类为将来的类提供了重写/更改其某些行为的能力。

因此，如果您有删除虚拟关键字的规则，则可能没有预期的效果。

C ++中的virtual关键字是一个强大的概念。您应该确保团队的每个成员都真正了解这个概念，以便可以按设计使用它。

根据您的平台，虚拟呼叫的开销可能非常不理想。通过声明每个虚拟函数，您实际上是通过函数指针全部调用它们。至少这是额外的取消引用，但是在某些PPC平台上，它将使用微码或慢速指令来完成此操作。

出于这个原因，我建议您反对您的建议，但是如果它可以帮助您防止错误，那么值得进行权衡。但是，我不禁认为必须找到一些中间立场。

只需几个额外的asm指令即可调用虚拟方法。

但我不认为您会担心fun（int a，int b）与fun（）相比有一些额外的“推送”指令。因此，也不必担心虚拟机，直到您处于特殊情况并看到它确实会导致问题为止。

PS如果您有一个虚拟方法，请确保您有一个虚拟析构函数。这样您将避免可能的问题

作为对“ xtofl”和“ Tom”评论的回应。我用3个功能进行了小型测试：

1. 虚拟
2. 正常
3. 正常，带有3个int参数

我的测试是一个简单的迭代：

for(int it = 0; it < 100000000; it ++) {
    test.Method();
}

结果如下：

1. 3,913秒
2. 3873秒
3. 3,970秒

它是由VC ++在调试模式下编译的。我每个方法仅进行了5次测试，并计算了平均值（因此结果可能非常不准确）...不管怎样，假设有1亿次调用​​，这些值几乎相等。而且带有3个额外的push / pop的方法比较慢。

要点是，如果您不喜欢与push / pop进行类比，那么在代码中考虑其他if / else吗？你想想CPU流水线当你添加额外的if / else ;-)而且，你永远不知道什么CPU的代码将运行......常见的编译器生成的代码更优化的一个CPU和优化的较少为其他（英特尔C ++编译器）