4

プロジェクトのコンパイルには時間がかかり、コンパイル時間を改善したいと思いました。私が最初にやろうとしていることは、コンパイル時間を個々のファイルに分解することです。

たとえば、コンパイラが次のように指示します。

boost/variant.hpp: took 100ms in total
myproject/foo.hpp: took 25ms in total
myproject/bar.cpp: took 125ms in total

次に、前方宣言を導入したり、インクルードファイルを省略できるように並べ替えたりすることで、最も時間がかかるファイルのコンパイル時間を具体的に改善することができます。

このタスクに何かありますか？GCCとICC（Intel c ++）を使用しています

ビルドシステムとしてSconsを使用しています。

4

3 に答える 3

2

重要なメトリックは、ヘッダーファイルの処理にかかる時間（意味が何であれ）ではなく、ヘッダーファイルが変更され、ビルドシステムがすべての依存ユニットでコンパイラーを再起動するように強制する頻度です。

コンパイラが役に立たないコードの解析に費やす時間は、コンパイルプロセスの他のすべてのステップと比較して非常に短いです。不要なファイル全体を含めたとしても、それらはディスクキャッシュで高温になっている可能性があります。そして、プリコンパイル済みヘッダーはこれをさらに良くします。

目標は、ヘッダーファイルの無関係な変更によるユニットの再コンパイルを回避することです。そこで、pimplやその他のコンパイルファイアウォールなどの手法が登場します。

また、リンク時のコード生成、つまりプログラム全体の最適化は、コンパイル時のファイアウォールを元に戻し、プログラム全体を再処理することで、事態をさらに悪化させます。

とにかく、ヘッダーファイルがどれほど不安定であるかに関する情報は、ビルドログ、コミットログ、さらにはファイルシステムの最終変更日から取得できるはずです。

于 2012-12-17T18:13:10.007 に答える
2

ヘッダーファイルの処理に費やされた時間の、他の人が使用しているものと一致しない、変わった、風変わりな定義があります。したがって、おそらくこれを実現することはできますが、自分で行う必要があります。おそらく最良の方法は、のgcc下で実行することstrace -ttです。次に、各ファイルを開いたり、読み取ったり、閉じたりするタイミングを確認して、ファイルの処理時間を確認できます。

于 2012-12-17T18:04:26.007 に答える
2

ビルド全体をインストルメント化してみましたか？他のパフォーマンスの問題と同様に、問題だと思うのは実際には問題ではない可能性があります。 Electric Makeは、GNU-makeと互換性のあるmakeの実装であり、XML注釈付きのビルドログを生成できます。このログは、ElectricInsightでのビルドパフォーマンスの問題の分析に使用できます。たとえば、ElectricInsightの「タイプ別のジョブ時間」レポートでは、ビルドで最も時間がかかるアクティビティ、具体的にはビルドで最も長いジョブを幅広く知ることができます。それはあなたが彼らが最も実りある場所にあなたの努力を向けるのを助けるでしょう。

例えば：

ここに画像の説明を入力してください

免責事項：私はElectricMakeとElectricInsightのチーフアーキテクトです。

于 2012-12-17T18:31:34.807 に答える