“价格”是多少？在带有 C++ 的嵌入式环境中使用继承？

Question

我正在使用 C++ 开始一个新的嵌入式项目，我想知道使用面向接口的设计是否太昂贵。像这样的东西：

typedef int data;

class data_provider {

public:
    virtual data get_data() = 0;
};

class specific_data_provider : public data_provider {
public:
    data get_data() {
    return 7;
    }
};

class my_device {
public:
    data_provider * dp;
    data d;

    my_device (data_provider * adp) {
    dp = adp;
    d = 0;
    }

    void update() {
    d = dp->get_data();
    }
};

int
main() {
    specific_data_provider sdp;
    my_device dev(&sdp);

    dev.update();

    printf("d = %d\n", dev.d);

    return 0;
}

Answer 1

继承本身是免费的。例如，如下所示，从性能/内存的角度来看，B 和 C 是相同的：

struct A { int x; };
struct B : A { int y; };
struct C { int x, y; };

只有当您拥有虚拟函数时，继承才会产生成本。

struct A { virtual ~A(); };
struct B : A { ... };

在这里，在几乎所有实现中，由于虚拟函数的原因，A 和 B 的指针大小都会大一个。

虚函数还具有其他缺点（与非虚函数相比）

1. 虚函数要求您在调用时查找 vtable。如果该 vtable 不在缓存中，那么您将遇到 L2 未命中，这在嵌入式平台上可能会非常昂贵（例如，在当前一代游戏机上超过 600 个周期）。
2. 即使您命中 L2 缓存，如果您分支到许多不同的实现，那么您可能会在大多数调用上得到分支错误预测，从而导致管道刷新，这又会花费许多周期。
3. 由于虚拟函数基本上不可能内联（除了极少数情况），您还会错过许多优化机会。如果您调用的函数很小，那么与内联非虚拟函数相比，这可能会增加严重的性能损失。
4. 虚拟调用会导致代码膨胀。每个虚拟函数调用都会添加几个字节的指令来查找 vtable，以及用于 vtable 本身的许多字节。

如果您使用多重继承，那么事情会变得更糟。

通常人们会告诉您“在分析器告诉您之前不要担心性能”，但如果性能对您来说非常重要，那么这是一个糟糕的建议。如果您不担心性能，那么最终会出现到处都是虚拟函数的情况，并且当您运行探查器时，没有一个热点需要优化——整个代码库都需要优化。

我的建议是，如果性能对您很重要，则进行设计。如果可能的话，设计时应避免使用虚拟函数。围绕缓存设计数据：更喜欢数组而不是基于节点的数据结构，例如 std::list 和 std::map。即使您有一个包含数千个元素的容器，并且经常在中间插入，我仍然会在某些架构上选择数组。复制插入数据时丢失的数千个周期很可能会被每次遍历时实现的缓存局部性所抵消（还记得单个 L2 缓存未命中的成本吗？您可以预期其中很多当遍历链表时）

Answer 2

继承基本上是免费的。然而，多态性和动态分派（虚拟）会带来一些后果：具有虚拟方法的类的每个实例都包含一个指向vtable的指针，该指针用于选择正确的方法。方法来调用。这为每个虚拟方法调用增加了两次内存访问。

在大多数情况下，这不会成为问题，但它可能成为某些实时应用程序的瓶颈。

Answer 3

确实取决于您的硬件。继承本身可能不会花费您任何费用。虚拟方法会为每个类中的 vTable 消耗一定量的内存。打开异常处理可能会消耗更多的内存和性能。我在 NetBurner 平台上广泛使用了 C++ 的所有功能，其中包括 MOD5272 等芯片，该芯片具有几兆闪存和 8 兆 RAM。另外，有些事情可能与实现相关，取决于我使用的 GCC 工具链，当使用 cout 而不是 printf 时，您会占用大量内存（它似乎链接到一堆库）。您可能对我撰写的关于成本的博客文章感兴趣类型安全代码。您必须在您的环境中运行类似的测试才能真正回答您的问题。

Answer 4

通常的建议是使代码清晰和正确，然后只有在实践中证明是一个问题（太慢或内存太多）时才考虑优化。