-pipe不能直接提高编译速度，但通过管道传递中间数据减少临时文件I/O开销，在磁盘I/O瓶颈场景（如机械硬盘、NFS、CI/CD共享存储）可降低5–10%总体编译时间。
不能直接提高编译速度，但能减少临时文件 I/O 开销，对大型项目有可测量的加速效果。
为什么-pipe不等于“更快编译”
-pipe 的作用是让 GCC 在编译阶段（预处理 → 编译 → 汇编）之间用管道（pipe）传递数据，而不是写入临时文件（如 .i、.s）。它不改变优化逻辑、不跳过任何步骤，也不缩短单个阶段耗时。
实际影响取决于你的构建环境：
- SSD 速度快时，
-pipe带来的收益可能不到 1%； - 机械硬盘或 NFS 挂载目录下，临时文件读写成为瓶颈，
-pipe可降低 5–10% 总体编译时间； - 内存充足时，管道缓冲区基本无压力；内存紧张时，可能增加 swap 使用（极少见，但需留意）。
什么时候该加-pipe
不是所有场景都值得启用。它真正起作用的地方是：
- 项目包含大量小源文件（如 >1000 个
.cpp），且构建系统未做有效并行控制； - 使用
make -j并行编译时，多个编译进程同时争抢磁盘 I/O ——-pipe能缓解这一竞争； - CI/CD 环境中磁盘 I/O 是已知瓶颈（例如某些云构建节点配的是低速共享存储）；
- 你明确观察到
gcc进程在write()或open()系统调用上阻塞（可用strace -e trace=write,open gcc ...验证）。
容易被忽略的兼容性问题
-pipe 在绝大多数现代 Linux/macOS 环境下工作良好，但以下情况要小心：
- 某些嵌入式交叉工具链（如旧版
arm-linux-gnueabihf-gcc）不支持管道，会报错cannot execute 'cc1': No such file or directory或静默失败； - 配合
-save-temps使用时，-pipe会被忽略（因为必须生成中间文件）； - Windows 上 MinGW-w64 默认不支持
-pipe，启用后可能触发fork: Resource temporarily unavailable错误（尤其在 MSYS2 中）； - 容器内运行时若
/dev/shm大小受限（如 Docker 默认 64MB），大文件管道可能卡住或失败。
它不是银弹，但如果你的构建日志里频繁出现磁盘等待、或者 time make 显示 I/O wait 占比高，-pipe 就值得试一次——加在 CFLAGS 或 CXXFLAGS 里即可，无需改其他逻辑。
