7

我正在尝试在应用程序架构中非常低的级别对我的代码进行微优化。所以这是我的具体场景：

  • 我有一个解析器类，它解析图形文件（节点、边、邻接条目等）
  • 文件格式是版本化的，因此每个版本都存在解析器，它们被实现为单独的类（ParserV1、ParserV2、...）。
  • 解析器为应用程序中的某些上层提供相同的功能。因此，它们实现了相同的“接口”。
  • 在 C++ 中，我会将这样的接口实现为一个抽象类，其中所有函数都是纯虚拟的。
  • 由于虚函数需要另一个内存查找，并且不能在编译时静态绑定，而且——更重要的是——不允许在解析器类中内联小方法，使用经典的子类化习惯不会导致我能达到的最佳表现。

[在描述我可能的解决方案之前，我想解释一下为什么我在这里做微优化（你可以跳过这一段）：解析器类有很多小方法，其中“小”意味着他们没有做太多. 它们中的大多数只从缓存的比特流中读取一两个字节，甚至只读取一个比特。所以应该有可能以一种非常有效的方式来实现它们，其中一个函数调用，当内联时，只需要少量的机器命令。这些方法在应用程序中被非常频繁地调用，因为它们在一个非常大的图表（全球道路网络）中查找节点属性，每个用户请求可能发生大约一百万次，并且这样的请求应该与可能的。]

去这里的路是什么？我可以看到以下解决问题的方法：

  1. 使用纯虚方法编写接口并将其子类化。性能会受到影响。
  2. 不要写这样的接口。每个解析器自己定义相同的方法。在上层（使用解析器）有指向每个版本子类的指针（作为成员）。一开始，实例化应该使用的特定解析器。每当访问函数时，使用 switch 块并将解析器实例强制转换为显式子类。性能会更好吗？（if/switch 块与虚拟表查找）。
  3. 混合两种解决方案 1. + 2.：为很少使用的方法编写一个带有纯虚拟方法的接口，其中性能不是很关键。如果很关键，不要提供虚拟方法，而是使用第二种方法。
  4. 改进2.：在抽象类中提供非虚方法；在抽象类中保留版本号作为成员变量（一种自己的运行时类型信息），并在这些方法中实现 if/switch 块和强制转换；然后调用子类中的方法。这提供了内联和静态绑定。

有没有更好的方法来解决这个问题？这有什么成语吗？

澄清一下，我有很多与版本无关的函数（至少到现在为止），因此非常适合某些超类。我将对大多数函数使用标准的子类化设计，而这个问题仅涵盖要优化的版本相关函数的解决方案。（其中一些调用不频繁，在这些情况下我当然可以使用虚拟方法。）除此之外，我不喜欢让解析器类决定哪些方法需要高性能，哪些方法不需要. （尽管这样做是可能的。）

4

2 回答 2

3

一个可能会很好的选项如下：让每个解析器类定义具有相同签名的方法，但完全独立于其他类。然后，引入一个虚拟实现所有这些相同功能的二级类层次结构，然后将每个方法调用转发到一个具体的解析器对象。这样，解析器的实现就获得了内联的所有好处，因为从类的角度来看，所有调用都可以静态解析，而客户端则获得了多态性的好处，因为任何方法调用都会动态解析为正确的类型。

这样做的问题是您使用了额外的内存（包装对象占用了空间），并且当您调用解析器函数时，您可能还会至少涉及一个额外的间接寻址，因为调用是

客户端→包装器→实现

根据您从客户端调用方法的频率，此实现可能会很好地工作。

使用模板，可以非常简洁地实现包装层。思路如下。假设您有方法 fA、fB 和 fC。首先定义一个像这样的基类：

class WrapperBase {
public:
    virtual ~WrapperBase() = 0;

    virtual void fA() = 0;
    virtual void fB() = 0;
    virtual void fC() = 0;
};

现在，将以下模板类型定义为子类：

template <typename Implementation>
    class WrapperDerived: public WrapperBase {
private:
    Implementation impl;

public:
    virtual void fA() {
        impl.fA();
    }
    virtual void fB() {
        impl.fB();
    }
    virtual void fC() {
        impl.fC();
    }
};

现在，您可以执行以下操作：

WrapperBase* wrapper = new WrapperDerived<MyFirstImplementation>();
wrapper->fA();
delete wrapper;

wrapper = new WrapperDerived<MySecondImplementation>();
wrapper->fB();
delete wrapper;

换句话说，编译器只需实例化WrapperDerived模板即可为您生成所有包装器代码。

希望这可以帮助！

于 2012-07-02T22:42:35.377 回答
2

首先，当然，您应该分析您的代码，以确定在您的特定情况下有多少 vcalls 性能下降（除了可能较弱的优化之外）。

将优化主题放在一边，我几乎可以肯定，通过调用编译时的开关替换虚函数调用（或通过指针变量调用函数，几乎相同）不会获得任何显着的性能提升 -不同情况下的已知函数。

如果您真的想要显着改进-恕我直言，这些是最有希望的变体：

  1. 尝试重新设计您的界面以启用更复杂的功能。例如，如果您有一个读取单个顶点的函数 - 将其修改为一次读取（最多）N 个顶点。等等。

  2. 您可以使您的整个解析代码（使用您的解析器）成为一个template类/函数，它将使用模板参数来实例化所需的解析器。在这里，您既不需要接口也不需要虚函数。在最开始（您识别版本的位置） - 放置一个switch, 对于每个识别的版本，使用适当的模板参数调用此函数。

从性能的角度来看，后者可能会更优越，OTOH 这增加了代码大小

编辑：

以下是 (2) 的示例：

template <class Parser>
void MyApplication::HandleSomeRequest(Parser& p)
{
    int n = p.GetVertexCount();
    for (iVertex = 0; iVertex < n; iVertex++)
    {
        // ...    
        p.GetVertexEdges(iVertex, /* ... */);    
        // ...    
    }
}

void MyApplication::HandleSomeRequest(/* .. */)
{
    int iVersion = /* ... */;
    switch (iVersion)
    {
    case 1:
        {
            ParserV1 p(/* ... */);
            HandleSomeRequest(p);
        }
        break;

    case 2:
        {
            ParserV2 p(/* ... */);
            HandleSomeRequest(p);
        }
        break;

    // ...
    }
}

类ParserV1等ParserV2没有功能。_ virtual它们也不继承任何接口。他们只是实现了一些功能，例如GetVertexCount.

于 2012-07-02T22:48:39.710 回答