我应该什么时候使用GCC的pipe道选项？
GCC 4.1.2文档有关于-pipe选项的说明：
-pipe
在编译的各个阶段之间使用pipe道而不是临时文件进行通信。 这在汇编器无法从pipe道读取的某些系统上无法工作; 但GNU汇编器没有问题。
我想我可以从错误消息中知道我的系统的汇编程序是否不支持pipe道，所以除了这个问题，我使用这个选项的时候什么时候关心？ 决定使用它的因素有哪些？
通常没有任何区别
它有+和– 的考虑。 从历史上看，同时运行编译器和汇编器会压缩RAM资源。
按照今天的标准，Gcc很小， -pipe增加了一些多核可访问的并行执行。
但同样的道理，CPU速度如此之快，以至于它可以创build临时文件并在不知不觉中将其读回来。 而由于-pipe从来不是默认模式，所以偶尔会出现一些问题。 一个开发者通常会报告没有注意到时间差异。
现在，有一些大型项目。 你可以看看一个能构build所有Firefox或者NetBSD的树，这个东西真的很大。 包含所有X的东西，例如，作为次要子系统组件。 当工作涉及成千上万个C文件中的数百万行代码时，您可能会也可能不会注意到这些差异。 正如我确信你知道的，人们通常只是在这样的一小部分工作。 但是如果你是一个发布工程师，或者在构build服务器上工作，或者在stdio.h中改变某些东西，那么你可能需要构build整个系统来查看是否破坏了任何东西。 而现在，每一滴的performance可能都是重要的…
根据我们对一个中等规模项目的经验，添加-pipe在build造时间上没有明显的差别。 我们遇到了一些问题（有时如果遇到错误，有时候不能删除中间文件，IIRC），所以我们没有得到任何东西，所以不再使用它，而是试图解决这些问题。
现在尝试一下，当源/目标位于NFS（linuxnetworking）上时，它看起来要快一些。 内存使用率虽然高。 如果你从来没有填充内存，并在NFS上有源代码，看起来像一个与pipe道的胜利。
老实说，没有理由不使用它。 – pipe只会使用更多的内存，如果这个盒子是build筑的代码，我会假设有一个体面的数额。 如果你的系统使用了一个更保守的文件系统，那么这个文件系统可以显着地提高编译时间，这个文件系统写入并删除所有的临时文件（例如ext3）。
其中一个优点是，使用-pipe编译器可以减less与文件系统的交互。 即使是RAM磁盘，在使用临时文件时，数据仍然需要通过块I / O和文件系统层，而使用pipe道时，数据会变得更加直接。
编译器在调用汇编程序之前首先需要完成写入操作。 pipe道的另一个优点是编译器和汇编程序都可以同时运行，并且可以更多地使用SMP体系结构。 特别是当编译器需要等待来自源文件的数据（由于阻塞I / O调用）时，操作系统可以给汇编器全部的CPU时间，并且使其更快地工作。
从硬件的angular度来看，我想你会使用-pipe来保存硬盘的使用寿命。
