GCC 4.1.2のドキュメントには、-pipeオプションについて次のように記載されています。
-パイプ
コンパイルのさまざまな段階間の通信には、一時ファイルではなくパイプを使用します。これは、アセンブラがパイプから読み取ることができない一部のシステムでは機能しません。しかし、GNUアセンブラには問題はありません。
システムのアセンブラがパイプをサポートしていないかどうかをエラーメッセージから判断できると思いますが、その問題以外に、そのオプションを使用するかどうかはいつ重要ですか？それを使用することを決定する際にどのような要素を考慮する必要がありますか？
+と-の考慮事項があります。歴史的に、コンパイラとアセンブラを同時に実行すると、RAMリソースに負荷がかかります。
Gccは今日の標準では小さく、-pipeマルチコアでアクセス可能な並列実行を少し追加します。
しかし、同じように、CPUは非常に高速であるため、気付かないうちに一時ファイルを作成して読み戻すことができます。また-pipe、デフォルトモードではなかったため、ときどき少し動作します。通常、1人の開発者が時差に気づかないと報告します。
今、そこにいくつかの大きなプロジェクトがあります。Firefox、NetBSD、またはそのようなものすべてを構築する単一のツリーをチェックアウトすることができます。これは本当に大きなものです。たとえば、マイナーサブシステムコンポーネントとしてXのすべてを含むもの。ジョブに数千、数千のCファイルに数百万行のコードが含まれている場合、違いに気付く場合と気付かない場合があります。ご存知のように、人々は通常、一度にこのようなもののごく一部にしか取り組みません。ただし、リリースエンジニアであるか、ビルドサーバーで作業している場合、またはstdio.hで何かを変更している場合は、システム全体をビルドして、何かが壊れていないかどうかを確認することをお勧めします。そして今、パフォーマンスのすべての低下はおそらく重要です...
中規模のプロジェクトでの経験では、追加-pipeしてもビルド時間に認識できる違いはありませんでした。いくつかの問題が発生しました（エラーが発生した場合に中間ファイルの削除に失敗することがあります、IIRC）。そのため、何も得られなかったため、これらの問題のトラブルシューティングを試みるのではなく、使用を中止しました。
今これを試してみると、ソース/ビルドの宛先がNFS（Linuxネットワーク）上にある場合、ビルドは適度に高速であるように見えます。ただし、メモリ使用量は多くなります。RAMをいっぱいにせず、NFSにソースがある場合は、-pipeを使用すると成功するようです。
正直なところ、それを使用しない理由はほとんどありません。-パイプは少し多くのRAMのみを使用します。このボックスが建築基準法である場合、かなりの量があると思います。システムが途中ですべての一時ファイル（たとえば、ext3）を書き込んでから削除する、より保守的なファイルシステムを使用している場合は、ビルド時間を大幅に改善できます。
1つの利点は、-pipeを使用すると、コンパイラーがファイルシステムとの対話が少なくなることです。RAMディスクの場合でも、一時ファイルを使用する場合、データはブロックI / Oおよびファイルシステムレイヤーを通過する必要がありますが、パイプを使用すると、データはもう少し直接的になります。
ファイルの場合、コンパイラはアセンブラを呼び出す前に、最初に書き込みを完了する必要があります。パイプのもう1つの利点は、コンパイラーとアセンブラーの両方を同時に実行できることと、SMPアーキテクチャーをもう少し活用していることです。特に、コンパイラがソースファイルからのデータを待機する必要がある場合（I / O呼び出しをブロックするため）、オペレーティングシステムはアセンブラに完全なCPU時間を与え、そのジョブをより高速に実行させることができます。
ハードウェアの観点から-pipeは、ハードドライブの寿命を延ばすために使用すると思います。