GCC 9.4.0中短字符串优化为何比堆分配更慢？

你测试的代码如下：

#include <string>
int main(int argc, const char *argv[])
{
    const size_t size = strtoull(argv[1], nullptr, 10);
    for (int i = 0; i < 100000000; ++i)
    {
        std::string str;
        str.reserve(size);
        for (size_t j = 0; j < size; ++j)
        {
            str += 'x';
        }
    }
    return 0;
}

通过g++ string-append.cpp -O3 -o string-append编译后，出现了反直觉的性能差异：

$ time ./string-append 15

real    0m4.342s
user    0m4.342s
sys     0m0.000s

$ time ./string-append 16

real    0m3.112s
user    0m3.112s
sys     0m0.000s

核心现象验证 #

通过工具验证得到：

• 参数15：无堆分配，str.c_str()始终返回同一栈地址（触发短字符串优化SSO）
• 参数16：发生1亿次堆分配/释放，str.c_str()地址每次变化（使用堆存储）
• 参数16的perf统计显示更多L1缓存加载/存储/缺失、分支指令、分支预测失败、指令数（几乎多一倍），但运行速度更快

原因拆解 #

1. GCC libstdc++的SSO实现细节 #

GCC 9.4.0配套的libstdc++中，std::string的SSO缓冲区大小为15字节：

• 当字符串长度≤15时，数据直接存储在栈上的字符串对象内部：对象首字节存储长度，后续15字节为字符缓冲区
• 当长度≥16时，字符串对象存储堆指针、长度、容量三个字段，数据存放在堆上

你的代码中，reserve(15)完全使用栈上SSO缓冲区，无需堆分配；reserve(16)则直接触发堆内存分配。

2. 编译器优化能力差异：SSO场景无法被高效优化 #

尽管SSO避免了堆分配的开销，但GCC 9.4.0对SSO场景的循环代码优化存在局限性：

• 堆分配场景：reserve(16)后，编译器能识别出循环16次str += 'x'等价于将堆缓冲区全部填充为'x'，进而将循环替换为高效的批量内存操作（如memset或向量指令）。虽然指令数更多，但这类批量操作的执行吞吐量远高于单字节逐次赋值。
• SSO场景：由于SSO的长度存储在单独的1字节字段中，且缓冲区位于栈上，GCC无法将逐次append的循环优化为批量操作，只能保留逐字节赋值+长度递增的逻辑。这种单字节循环的执行效率远低于批量内存操作，抵消了SSO无堆分配的优势。

3. 分支与缓存行为的影响 #

SSO场景中，每次str += 'x'都会触发内部的分支检查（判断当前长度是否在SSO范围内），尽管reserve已保证容量足够，但libstdc++的append实现仍保留了该分支逻辑。循环中反复执行的分支会增加分支预测失败的概率，进一步拖慢执行速度。

而堆分配场景的append分支逻辑更简单，且批量内存操作的连续访问模式更利于缓存命中，弥补了堆分配的开销。

4. 编译器版本差异 #

Clang 13未出现此问题，是因为Clang对SSO场景的循环优化能力更强，能识别出SSO缓冲区的批量赋值模式，将循环转化为高效操作，消除了SSO与堆分配之间的性能差距。

总结 #

GCC 9.4.0对std::string SSO场景的循环优化不足，导致逐字节赋值的开销超过了堆分配+批量操作的总开销。升级到更高版本的GCC（如GCC 10及以上）或切换到Clang编译器，均可解决此性能异常问题。

内容的提问来源于stack exchange，提问作者chicken-rice