私はg++を使用して、約15個のc++ソースファイルと4個の共有オブジェクトファイルで構成されるプロジェクトをコンパイルおよびリンクしています。最近、リンク時間が2倍以上になりましたが、makefileの履歴を利用できません。リンクのどの部分に時間がかかっているかを確認するためにg++のプロファイルを作成する方法はありますか？
編集： makefileが常に-O3最適化を使用していることに気付いた後、そのスイッチを削除するだけでリンク時間を半分にすることができました。試行錯誤せずにこれを見つけることができた良い方法はありますか？
編集：私は実際にldがどのように機能するかをプロファイリングすることに興味がありません。特定のコマンドラインスイッチまたはオブジェクトファイルへのリンク時間の増加をどのように一致させることができるかを知りたいです。
RAM の制限に達したばかりの場合は、おそらくディスクの動作を聞くことができ、システム アクティビティ モニターがそれを知らせてくれます。しかし、リンクがまだ CPU バウンドである場合 (つまり、CPU 使用率がまだ高い場合)、それは問題ではありません。また、リンクが IO バウンドである場合、最も一般的な原因はランタイム情報である可能性があります。とにかく実行可能サイズを見てください。
別の方法で問題に答えるには、テンプレートを頻繁に使用していますか? 異なる型パラメーターを持つテンプレートを使用するたびに、テンプレート全体の新しいインスタンスが生成されるため、リンカーの作業が増えます。ただし、これを実際に目立たせるには、テンプレートが非常に多いライブラリを使用する必要があります。Boost プロジェクトの多くのものが該当します - Boost::Spirit を複雑な文法で使用すると、テンプレート ベースのコードが肥大化します。そして、7,7M の実行可能ファイルにコンパイルされた約 4000 行のコード - 1 行を変更すると、必要な特殊化の数と最終的な実行可能ファイルのサイズが 2 倍になりました。ただし、インライン化は大いに役立ち、1.9M の出力につながりました。
共有ライブラリが他の問題を引き起こしている可能性があります。-fvisibility=hidden のドキュメントを参照すると、とにかくコードが改善されます。-fvisibility の GCC マニュアルから:
Using this feature can very substantially improve linking and load times of shared object libraries, produce more optimized code, provide near-perfect API export and prevent symbol clashes. It is *strongly* recommended that you use this in any shared objects you distribute.
実際、リンカーは通常、アプリケーションまたは他のライブラリがライブラリに定義されたシンボルをオーバーライドする可能性をサポートする必要がありますが、通常、これは意図された使用法ではありません。それを使用するのは無料ではありませんが、(些細な) コード変更が必要であることに注意してください。
ドキュメントで提案されているリンクは次のとおりです。http://gcc.gnu.org/wiki/Visibility
はリンクを実行せず、リンカーが実行するため、プロファイリングg++は無駄であることがわかります。g++ld
リンク時間はほとんどの場合、ディスク I/O によって支配されているため、プロファイリングldでも興味深い結果が得られない可能性があります。リンクがそうでない場合は、ld内部を理解していない限り、プロファイリング データをどう処理すればよいかわかりません。
リンク内に 15 個のファイルしかないのにリンク時間が目立つ場合は、開発システムに問題がある可能性があります [1]。最後のレグにあり、常に再試行しているディスクがあるか、リンクを実行するのに十分なメモリがなく (リンクは多くの場合、RAM を集中的に使用します)、システムが狂ったようにスワップします。
ELF ベースのシステムを使用していると仮定すると、新しいgoldリンカー (binutils の一部) を試してみることもできます。これは、多くの場合、GNU よりも数倍高速ですld。
[1] 私の典型的なリンクには、数千のオブジェクトが含まれ、200 MB 以上の実行可能ファイルが生成され、60 秒未満で終了します。