18

私は巨大なプロジェクトを持っています。C++コードの約150000LOCです。ビルド時間は約15分です。このプロジェクトは、さまざまなサイズの多くのサブプロジェクトで構成されています。

サブプロジェクトごとに個別のプリコンパイル済みヘッダーを作成しましたが、それらを使用すると、作成時間はほぼ同じになります。ビルド時間は5〜10％短縮され、それ以上ではないようです。

プリコンパイル済みヘッダーは間違いなく使用されています。オプションを使用し、コンパイラオプションを使用-Winvalid-pchしてコンパイルしようとしました-H。プリコンパイル済みヘッダーは、出力に「bang」記号で表示されます。これは、コンパイラがプリコンパイル済みヘッダーを使用できることを意味します。

私のプリコンパイル済みヘッダーはすべてそれほど大きくはなく、すべてのファイルは約50Mbです。ここにあるpythonスクリプトを使用して、最も使用されているプリコンパイル済みヘッダーのリストを生成しているので、プリコンパイル候補のリストは非常に優れています。

ビルドを最適化するための無料/オープンソースツールはありますか？標準makeユーティリティには、さまざまなターゲットのビルド時間を測定する機能がないようです。を使用してさまざまなターゲットの統計を取得する方法が見つかりませんmake。依存関係の分析や高度なことについて話しているのではありません。ほとんどの場合、どのターゲットが無駄になっているのか知りたいだけです。

また、GCCはプリコンパイル済みヘッダーの処理において非常に非効率的であるように見えました。サブプロジェクトのビルドを著しく速くすることはできませんでした。ビルドに3分かかるプロジェクトでは、最大スピードアップは20％です。GCCを使用したLinuxでのビルド時間を最適化するよりも、ソリッドステートドライブを備えた高速のマシンを購入する方が簡単で安価なようです。

4

4 に答える 4

11

GCCのビルド時間は、プリコンパイル済みヘッダーの恩恵をあまり受けません

はい、残念ながらそれはしばしば真実です、

より良いことをするためのいくつかの実験的なプロジェクトがあります。http：//www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3426.htmlおよびhttp://gcc.gnu.org/wikiを参照してください。 / pphですが、まだ使用できません。

150KLOCの15分はかなり遅いという他の答えに同意します。

Goldリンカーを使用すると、ビルド時間に大きな違いが生じることがわかりました。これを強くお勧めします。

また、役立つccacheを検討することもできます。また、他のマシンに予備のサイクルがある場合は、distcc

低速のディスクでの構築は避け、ネットワーク化されたディスクは避けてください。makefileの読み取りと依存関係グラフの再作成により多くの時間を費やす、再帰的な呼び出しmakeは避けてください。サブプロジェクトのmakefileを構造化して、すべてを1つのトップレベルのmakefileに含めることができる場合、非再帰的なmakeの開始には少し時間がかかりますが、ターゲットの構築が開始されると飛行します。ただし、makefileを書き直すのは大変な作業になる可能性があります。

言うまでもありませんが、マルチコアマシンで構築し、make -j N経験則としてN、コア数の2倍、またはコンパイルがI/Oバウンドの場合はそれ以上にする必要があります。

于 2012-11-13T01:09:24.990 に答える
6

この機能を最大限に活用したい場合は、プロジェクトをうまく活用するためにプロジェクトをどのように構成できるかを理解する必要があります。最善の方法は、ビルド時間を手動で短縮する、遅くて難しいプロセスです。最初は本当にばかげているように聞こえますが、今後のすべてのビルドが5倍速く、プロジェクトと依存関係を前進させる方法を知っていれば、見返りが得られます。

ターゲットとの継続的インテグレーションシステムをセットアップして、変更が加えられたときに進捗状況/改善を測定および記録できます。

私は巨大なプロジェクトを持っています。C++コードの約150000LOCです。ビルド時間は約15分です。このプロジェクトは、さまざまなサイズの多くのサブプロジェクトで構成されています。

あなたが現代のマシンを持っていると仮定すると、それは多くの冗長な仕事をしているように聞こえます。

リンク時間も考慮してください。

私のプリコンパイル済みヘッダーはすべてそれほど大きくはなく、すべてのファイルは約50Mbです。

それはかなり大きいです、IMO。

依存関係の分析や高度なことについて話しているのではありません。

繰り返しますが、統計の継続的インテグレーション。遅いビルドの場合、過度の依存関係が問題になる可能性が非常に高くなります（小さなcppファイルが多数ある場合、または物理メモリの枯渇などのばかげたものが発生している場合を除く）。

サブプロジェクトのビルドを著しく速くすることができませんでした。得られる最大スピードアップは20％です。

構造と依存関係を理解し​​ます。PCHは私のプロジェクトのほとんどを遅くします。

GCCを使用したLinuxでのビルド時間を最適化するよりも、ソリッドステートドライブを備えた高速のマシンを購入する方が簡単で安価なようです。

そのマシンではビルド時間が20倍速くなることはないかもしれませんが、依存関係とプロジェクト構造を修正すると、ビルド時間が20倍速くなる可能性があります（または問題の根本的な原因が何であれ）。マシンはそれほど役に立ちません（150KSLOCのビルド時間を考慮して）。

ビルドはおそらくCPU/メモリにバインドされています。

于 2012-11-12T07:29:10.343 に答える
0

PCHを生成して使用するときに-includeを使用して、多くのヘッダーを含むファイルをインクルードします。それは役に立ちますが、それでもそれほど印象的ではありません。

ただし、祝福を数えてください。MSVCのPCHサポートは優れていますが、gccはたとえばMSVCよりも数倍高速であるように見えます。

于 2012-11-13T04:13:57.793 に答える
0

現在、プロジェクトのビルド時間を改善しようとしています。プロジェクトはCMakeとGCCを使用し、Boostを使用した約100KのLOCです。

プリコンパイル済みヘッダーに切り替えることで、ビルドマシンでのビルド時間を43分から35分に改善することができました。GCCフラグを使用して-ftime-report各コンパイルフェーズのタイミングを取得し、ヘルパーPythonスクリプトを使用してすべてのコンパイルユニットのタイミングを合計しました。

これらのタイミングは、プリコンパイル済みヘッダーをプロジェクトに追加すると、解析と前処理のフェーズが大幅に削減される可能性があると同時に、コード生成と最適化のフェーズが大幅に増加する可能性があることを理解するのに役立ちました。これは、プリコンパイル済みヘッダーのすべてのデータを各コンパイルユニットに追加し、コンパイラーがこのデータも処理する必要があるためです。これらの2つの貢献に応じて、プリコンパイル済みヘッダーを使用することでメリットが得られる場合と得られない場合があります。

于 2020-05-16T15:57:52.800 に答える