我什么时候应该使用 GCC 的管道选项？

通常没什么区别

历史上，同时运行编译器和汇编器会增加 RAM 资源的压力。

按照今天的标准，Gcc 很小，而 -pipe增加了一点多核可访问的并行执行。

但是由于同样的原因，CPU 的速度是如此之快，以至于它可以创建那个临时文件，并在你甚至没有注意到的情况下读回它。而且因为 -pipe从来不是默认模式，所以偶尔会出现一些问题。单个开发人员通常会报告没有注意到时间差。

现在，有一些大型项目正在进行。您可以检查一个单独的树，它将构建所有 Firefox、 NetBSD 或类似的东西，非常大的东西。包含所有 X 的东西，比如说，作为一个次要的子系统组件。当这项工作涉及成千上万个 C 文件中的数百万行代码时，您可能会注意到，也可能不会注意到差异。我相信你们都知道，人们通常一次只做这种事情的一小部分。但是，如果您是一个发布工程师或者在构建服务器上工作，或者在 工作室,中更改某些内容，那么您可能希望构建整个系统，以查看是否破坏了某些内容。现在，每一次表演都很重要。

老实说，没有什么理由不使用它。管道只会使用多一点的内存，如果这个盒子是建筑代码，我想应该有不少。如果您的系统使用更为保守的文件系统，该文件系统写入并删除所有临时文件(例如 ext3) ，那么它可以显著提高构建时间

从硬件的角度来看，我想您会使用 -pipe来保持您的硬盘驱动器的生命周期。

根据我们在中型项目中的经验，添加 -pipe在构建时间上没有明显的差异。我们在使用它时遇到了一些问题(有时遇到错误时无法删除中间文件，如 IIRC) ，因此由于它没有给我们带来任何好处，我们放弃了使用它，而不是尝试解决这些问题。

现在尝试一下，当源/构建目的地位于 NFS (linux 网络)上时，构建速度似乎要快一些。但是内存使用率很高。如果您从来没有填充 RAM 并且在 NFS 上有源代码，那么似乎是一个双赢的方法。

一个优点是 with-tube 将使编译器与文件系统的交互减少。即使是内存磁盘，当使用临时文件时，数据仍然需要通过块 I/O 和文件系统层，而使用管道时，数据会变得更直接一些。

对于文件，编译器在调用汇编程序之前首先需要完成编写。管道的另一个优点是，编译器和汇编器都可以同时运行，而且它更多地使用了 SMP 架构。特别是当编译器需要等待来自源文件的数据时(由于阻塞 I/O 调用) ，操作系统可以给编译器充足的 CPU 时间，让它更快地完成工作。