使用std::views::join是否存在根本性性能开销？

问题背景 #

近期在评估C++20 ranges & views的性能时发现，针对编译期大小确定的std::array使用std::views::join，生成的汇编代码与直接访问元素的版本差异显著：

• sum_array（通过join访问）：31条指令、8次跳转
• sum_vec（直接访问数组内的vector）：12条指令、2次跳转

对应的测试代码如下：

#include <array>
#include <vector>
#include <ranges>

struct Foo {
    auto join() const { return m_array | std::views::join; }
    auto direct() const { return std::views::all(m_array[0]); }
    std::array<std::vector<int*>, 1> m_array;
};
__attribute__((noinline)) int sum_array(const Foo& foo)
{
    int result = 0;
    for (int* val : foo.join())
        result += *val;
    return result;
}
__attribute__((noinline)) int sum_vec(const Foo& foo)
{
    int result = 0;
    for (int* val : foo.direct())
        result += *val;
    return result;
}

核心原因：std::views::join的设计约束 #

这种差异并非编译器优化不到位，而是std::views::join的规格设计存在根本性限制：

• 通用适配的固有代价：join被设计为适配所有可拼接的range类型，包括运行时大小可变的range。即便输入是编译期大小固定的std::array，它也不能假设所有输入都具备编译期已知的大小，因此必须保留通用的range遍历框架，无法完全简化为直接访问单个vector的逻辑。
• 迭代器的分支逻辑：join_view的迭代器需要处理跨子range跳转的通用逻辑——哪怕场景中只有一个子range，迭代器仍会保留检测子range边界、切换下一个子range的分支判断，这些就是汇编中额外跳转的来源。
• 抽象层的开销：join返回的view类型包含比std::views::all更复杂的状态，当前GCC实现难以完全优化掉这些抽象带来的额外逻辑，尤其针对单元素array的特殊场景暂无针对性优化。

优化方向 #

• 编译器未来优化：后续编译器版本有可能针对“输入为编译期大小1的array”这类特殊场景做针对性优化，自动将join逻辑折叠为直接访问单个子range，但这属于非标准扩展优化，不能作为依赖。
• 手动简化实现：如果你的场景中m_array的大小始终是编译期已知的固定值（比如1），可以直接访问指定索引的元素，或者手动实现更轻量的拼接逻辑，避免std::views::join带来的通用层开销。

内容的提问来源于stack exchange，提问作者MarkB