14

假设我有以下元功能：

template <typename T>
struct make_pair {
    using type = std::pair<
        typename std::remove_reference<T>::type,
        typename std::remove_reference<T>::type
    >;
};

这样做（或其他）会提高编译速度吗？

template <typename T>
struct make_pair {
    using without_reference = typename std::remove_reference<T>::type;
    using type = std::pair<without_reference, without_reference>;
};

我看到两种可能性：

  1. 编译器每次看到typename std::remove_reference<T>::type. 使用中间别名有某种“缓存”行为，它允许编译器只做一次工作。

  2. 编译时性能是根据编译器必须执行的模板实例化的数量来衡量的。因为std::remove_reference<T>::type与 引用相同的类型std::remove_reference<T>::type，所以在两种情况下都只需要一个模板实例化，因此两种实现都是等效的 WRT 编译时性能。

我认为 B 是对的，但我想确定一下。如果答案是编译器特定的，我最有兴趣知道 Clang 和 GCC 的答案。

编辑：

我对测试程序的编译进行了基准测试，以便有一些数据可以使用。测试程序做这样的事情：

template <typename ...> struct result;    

template <typename T>
struct with_cache {
    using without_reference = typename std::remove_reference<T>::type;
    using type = result<without_reference, ..., without_reference>;
};

template <typename T>
struct without_cache {
    using type = result<
        typename std::remove_reference<T>::type,
        ...,
        typename std::remove_reference<T>::type
    >;
{ };

using Result = with[out]_cache<int>::type;

这些是程序 10 次编译的平均时间，其中包含 10 000 个模板参数result<>。

                -------------------------
                | g++ 4.8 | clang++ 3.2 |
-----------------------------------------
| with cache    | 0.1628s | 0.3036s     |
-----------------------------------------
| without cache | 0.1573s | 0.3785s     |
-----------------------------------------

测试程序由此处提供的脚本生成。

4

1 回答 1

2

我不能说所有编译器都是如此，但 GCC 以及很可能所有其他主要编译器都将使用 memoization。如果您考虑一下，几乎必须这样做。

考虑以下代码

&f<X, Y>::some_value == &f<X, Y>::some_value

这是必须的，因此编译器必须确保它不会重复方法和静态成员的定义。现在可能有其他方法可以做到这一点，但这只是让我尖叫记忆；我什至看不到另一种实现方式（当然，我已经非常努力地考虑过）

当我使用 TMP 时，我希望会发生记忆。如果不这样做，那将是一个真正的痛苦，太慢了。我看到编译时性能的主要差异的唯一方法是：a）使用更快的编译器，如 Clang（比 GCC 快 3 倍）并选择不同的算法。在我看来，小的常数因素在 TMP 中的影响甚至比在我的经验中对 C 或 C++ 的影响还要小。选择正确的算法，尽量不要做不必要的工作，尽量减少实例化的数量，并使用好的编译器（MSVC++真的很慢，远不符合 C++11，但 GCC 和 Clang 相当不错）；这就是你真正能做的。

此外，您应该始终牺牲编译时间以获得更好的代码。过早的编译时优化比普通的过早优化更邪恶。如果由于某种原因性能变得严重阻碍开发，则可能会有例外；然而，我从未听说过这样的案例。

于 2013-06-28T17:55:31.450 回答