GCC 4.1.2 文档对 -pipe 选项有这样的说法：

-pipe

Use pipes rather than temporary files for communication between the various stages of compilation. This fails to work on some systems where the assembler is unable to read from a pipe; but the GNU assembler has no trouble.

我假设我可以从错误消息中看出我的系统汇编程序是否不支持管道，所以除了这个问题之外，我何时使用该选项是否重要？决定使用它应该考虑哪些因素？

它有和 - 考虑因素。从历史上看，同时运行编译器和汇编器会对 RAM 资源造成压力。

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

但出于同样的原因，CPU 是如此之快，以至于它可以创建该临时文件并将其读回，而您甚至都不会注意到。而且由于 -pipe 从来都不是默认模式，因此它偶尔会起作用。单个开发人员通常会报告没有注意到时差。

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

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

现在尝试一下，当源/构建目标位于 NFS(Linux 网络)上时，它的构建速度似乎要快一些。虽然内存使用率很高。如果您从不填满 RAM 并且在 NFS 上有源代码，那么使用 -pipe 似乎是一场胜利。

老实说，几乎没有理由不使用它。 -pipe 只会使用更多的 ram，如果这个盒子是构建代码，我会假设它有一个不错的数量。如果您的系统使用更保守的文件系统，它可以显着缩短构建时间，该文件系统会在此过程中写入然后删除所有临时文件(例如 ext3。)

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

对于文件，编译器是否首先需要完成编写才能调用汇编器。管道的另一个优点是编译器和汇编器可以同时运行，并且更多地使用了 SMP 架构。特别是当编译器需要等待源文件中的数据时(因为阻塞 I/O 调用)，操作系统可以给汇编器充分的 CPU 时间，让它更快地完成工作。

从硬件的angular来看，我猜你会使用 -pipe 来保持硬盘的使用寿命。