GCC 4.1.2文档 对 -pipe
选项的解释如下:
-pipe
使用管道而不是临时文件来在编译过程的各个阶段之间进行通信。这种方式在某些系统上会失败,因为汇编器无法从管道读取数据;但GNU汇编器没有问题。
我认为如果我的系统汇编器不支持管道,就可以从错误消息中看出。那么除了这个问题,什么情况下使用该选项更为重要?决定是否使用该选项应考虑哪些因素?
GCC 4.1.2文档 对 -pipe
选项的解释如下:
-pipe
使用管道而不是临时文件来在编译过程的各个阶段之间进行通信。这种方式在某些系统上会失败,因为汇编器无法从管道读取数据;但GNU汇编器没有问题。
我认为如果我的系统汇编器不支持管道,就可以从错误消息中看出。那么除了这个问题,什么情况下使用该选项更为重要?决定是否使用该选项应考虑哪些因素?
它有+和-的考虑因素。从历史上看,同时运行编译器和汇编器会占用大量RAM资源。
Gcc在今天的标准下很小,-pipe
添加了一点多核可访问的并行执行。
但同样地,CPU速度非常快,它可以创建临时文件并读取它而您甚至都没有注意到。而且由于-pipe
从未是默认模式,它偶尔会出现一些问题。单个开发者通常不会注意到时间差异。
现在,有一些大型项目。您可以检查一个单独的树,将构建所有Firefox、NetBSD或类似的东西,即真正庞大的东西。例如,包含X的所有内容作为一个次要子系统组件。当工作涉及数百万行代码中的数千个C文件时,您可能会注意到差异,也可能不会。如您所知,人们通常只在一段时间内处理其中的一小部分内容。但如果您是发布工程师或正在构建服务器上工作,或正在更改stdio.h中的某些内容,则可能希望构建整个系统以查看是否有任何错误。现在,每一点性能都很重要...
在我们处理一个中等规模的项目时,添加-pipe
并没有明显的构建时间优势。我们遇到了一些问题(如果遇到错误有时无法删除中间文件,如果我没记错的话),所以因为没有带来任何好处,我们停止使用它而不是试图解决这些问题。
我现在正在尝试这个,当源代码/构建目标位于NFS(linux网络)时,构建速度似乎要快些。然而,内存使用率很高。如果您从未填满RAM并且将源代码放在NFS上,则使用-pipe似乎是一种胜利。
说实话,没有太多不使用它的理由。 -pipe 只会使用更少的 RAM,如果该系统正在构建代码,我认为RAM应该有足够的量。如果您的系统使用写入并在路上删除所有临时文件的更保守的文件系统(例如 ext3),它可以显着提高构建时间。
其中一个优点是使用-pipe选项时,编译器与文件系统的交互会更少。即使是在RAM磁盘上使用临时文件,数据仍然需要通过块I/O和文件系统层进行处理,而使用管道则更加直接。
使用文件时,编译器需要先完成写入操作,才能调用汇编器。使用管道的另一个优点是,编译器和汇编器可以同时运行,并更好地利用SMP架构。特别是当编译器需要等待源文件数据(因为阻塞I/O调用)时,操作系统可以将完整的CPU时间分配给汇编器,让其更快地完成工作。
从硬件角度来看,我想你可以使用-pipe
来保护您的硬盘寿命。