特定の状況で、動的リンクよりも静的リンクを選択する、またはその逆を選択する説得力のあるパフォーマンス上の理由はありますか? 私は次のことを聞いたり読んだりしたことがありますが、その真実性を保証できるほどこの件について十分な知識がありません。
1) 静的リンクと動的リンクの実行時パフォーマンスの違いは通常は無視できます。
2) プロファイルデータを使用してプログラムのホットパスを最適化するプロファイリングコンパイラを使用している場合、(1) は当てはまりません。静的リンクでは、コンパイラはコードとライブラリコードの両方を最適化できるためです。動的リンクでは、コードのみを最適化できます。ほとんどの時間がライブラリコードの実行に費やされる場合、これは大きな違いを生む可能性があります。それ以外の場合は、(1) が依然として適用されます。
ベストアンサー1
- ダイナミックリンクは、リソースの総消費量を削減することができます（複数のプロセスが同じライブラリを共有する場合（もちろん「同じ」バージョンも含む））。これが、ほとんどの環境でダイナミックリンクが使用される理由だと思います。ここでの「リソース」には、ディスク容量、RAM、キャッシュ容量が含まれます。もちろん、ダイナミックリンカーの柔軟性が不十分な場合は、DLL 地獄。
- 動的リンクとは、何も出荷しなくても、ライブラリのバグ修正やアップグレードが伝播して製品が改善されることを意味します。
- プラグインは常に動的リンクを呼び出します。
- 静的リンクとは、コードが非常に限られた環境(ブート プロセスの初期段階、またはレスキュー モード)で実行されることがわかることを意味します。
- 静的リンクを使用すると、バイナリをさまざまなユーザー環境に配布しやすくなります(ただし、送信するプログラムが大きく、リソースを大量に消費することになります)。
- 静的リンクを使用すると起動時間が若干速くなる可能性がありますが、これはプログラムのサイズと複雑さ、およびOS の読み込み戦略の詳細によってある程度異なります。
コメントや他の回答に非常に関連のある提案を含めるために編集しました。この問題を解決する方法は、実行環境によって大きく異なることに注意してください。最小限の組み込みシステムでは、動的リンクをサポートするのに十分なリソースがない場合があります。少し大きい小型システムでは、メモリが小さいため、動的リンクによる RAM の節約が非常に魅力的であるため、動的リンクをサポートする可能性があります。本格的なコンシューマー PC では、メモをマークする、膨大なリソースがあり、おそらく利便性の問題がこの問題に関するあなたの考えを左右するでしょう。
パフォーマンスと効率の問題に対処するには、状況によって異なります。
従来、動的ライブラリには何らかの接着層が必要であり、これは多くの場合、関数のアドレス指定における二重ディスパッチまたは間接参照の追加層を意味し、速度が若干低下する可能性があります (ただし、関数の呼び出し時間は実際に実行時間の大部分を占めるのでしょうか???)。
ただし、同じライブラリを頻繁に呼び出す複数のプロセスを実行している場合は、静的リンクを使用する場合と比較して、動的リンクを使用するとキャッシュ ラインを節約できます (したがって、実行パフォーマンスが向上します)。 (最新の OS が、静的にリンクされたバイナリ内の同一セグメントを認識できるほどスマートでない限り。難しいようですが、誰か知っていますか?)
もう 1 つの問題は、読み込み時間です。読み込みコストは、ある時点で発生します。このコストをいつ支払うかは、OS の動作方法と使用するリンクによって異なります。必要になるまで支払いを延期したほうがよいかもしれません。
静的リンクと動的リンクは、どちらもオブジェクト ファイルまでの個別のコンパイルを伴うため、従来は最適化の問題ではないことに注意してください。ただし、これは必須ではありません。コンパイラは、原理的には、最初に「静的ライブラリ」をダイジェストされた AST 形式に「コンパイル」し、それらの AST をメイン コード用に生成された AST に追加して「リンク」することで、グローバル最適化を強化できます。私が使用しているシステムではこれが行われていないため、それがどの程度うまく機能するかについてはコメントできません。
パフォーマンスに関する質問に答えるには、常にテストを行う必要があります (また、デプロイメント環境にできるだけ近いテスト環境を使用します)。