C++ 通过缓存元函数优化编译时性能

假设我有以下元函数：

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

---

测试程序是由可用的脚本生成的。

我不能说所有编译器都是如此，但GCC，以及最有可能的其他所有主要编译器，都将使用memonization。如果你想一想，它几乎是必须的

考虑以下代码

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

&f:：some_value==&f:：some_value

这要求为true，因此编译器必须确保它不会复制方法和静态成员的定义。现在也许有其他的方法可以做到这一点，但这对我来说只是一种尖叫；我甚至没有看到其他方法来实现这一点（当然，我已经仔细考虑过了）

当我使用TMP时，我希望能够实现记忆化。如果不是太慢，那将是一个真正的痛苦。我看到编译时性能的主要差异的唯一方法是a）使用更快的编译器，如Clang（比GCC快3倍），并选择不同的算法。在我看来，小的常数因素比TC中的C或C++更重要。选择正确的算法，尽量不做不必要的工作，尽量减少实例化的数量，并使用一个好的编译器（MSVC++速度非常慢，远远不符合C++11，但GCC和Clang非常好）；这就是你真正能做的

---

此外，您应该总是牺牲编译时间来获得更好的代码。过早的编译时优化比简单的过早优化更糟糕。如果出于某种原因，性能变得严重阻碍开发，则可能存在例外情况；然而，我从未听说过这种情况。

我认为任何猜测都无法取代实际测量。请发布一些计时数据，然后我们可以创建一个很好的理论来解释它们。我在clang上看到一个演讲，说他们为模板实例化而不是链表制作哈希表。但我不知道他们在拿自己和谁做比较。一个不进行记忆的

模板
编译器的速度会慢得离谱。@Yakk：另一方面，我看到gcc在一些输入上崩溃，因为它缓存了太多以至于超出了可用内存，而clang速度非常慢，但至少编译了beast（当然，我说的是荒谬的输入：p）。这个答案不错，但它不是我真正想要的。我想要的是更确定的东西，比如GCC或Clang开发人员的确认。另外，我问这个问题的原因是因为我一直在研究元编程库，优化那里的编译时间至关重要。
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;

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

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