ビルドシステムが、生成されたコードを深さ= 1のディレクトリ名で.soファイルにグループ化する大規模なC++プロジェクト（g ++/linux）を持っていますリンクするのが速いのはどちらですか？多くの小さな.soファイルまたはいくつかの大きな.soファイル？
これは、より小さな粒度をリリースするように、私はより細かく、すなわちdepth = 5とし、.soファイルの数を（5倍、20〜100）増加させようとしていますが、もっと細かくレベル
クリーンビルド中に、すべてがゼロから構築されているときに、小さな.soファイルが多数のリンク時間に影響しますか？
これはGNU/Linuxに関するものですか？
私たちは本当にこの問題を解決する必要があり、それが持っている：動的リンクは、依存関係のソートが約O（N³）またはその近辺であるアルゴリズムを使用しているため、現在は非常に遅いですまだ起こっていない。 （依存関係グラフにサイクルがあるときにソート順を変更することに心配する人もいるので、それは難しいです。）数十の共有オブジェクトがある場合、読み込み時間の影響は表示されませんが、あなたは100以上の問題があります。
リンクエディタのパフォーマンスについての最初の質問について：ELFの興味深い点の1つは、記号を含まないダミーDSOにリンクし、実行時に適切なDSOに置き換えられることです。-Wl,--unresolved-symbols=ignore-allと空依存関係が必要なすべてのsonamesにDSOがコピーされました。このトリックは、実行時の依存関係を無視して、ほとんどのものを並列にリンクさせることができます。これは、特に遅延バインディングを使用する場合は、プロダクションビルドのための素晴らしいアイデアではありませんが、開発中に役立つかもしれません。この変更により、多くの小さなDSOに物を分割することは価値がないかもしれません（しかし、実際にはあなたが現在扱っているライブラリのサイズに依存します）。
DSOの部分的なアップグレードは非常に厄介なことがあります。ユーザーがそれをしたら、依存関係を管理し、システム全体でABIの互換性を維持する必要があります。小規模なDSOでは、あるDSOから別のDSOに移動するシンボルの定義をもっと頻繁に処理する必要があります。これは、シンボルバージョンを使用する場合には不思議な障害につながります。
試しましたか？おそらく、プロジェクトごとに異なることになります。私はこの質問が少し広すぎると思う。しかし、私が推測するならば、私はそれがより遅いと想像するだろう。 – tambre
私は今それを試しています。詳細なリリースのメリットはコンパイル時間の増加を上回りますが、64GBのRAMを搭載した40コアマシンでコードをビルドするのに1時間以上かかる場合があります。 – zrb
dll粒度の基準は、実行ファイル間のマシンコードの共有である必要があります。ビルド時間に苦労している場合は、コードの構成を検査してタイミングを作成する必要があります。あなたのようなこの全話音は、何の理由もなく何千もの翻訳単位を放つ、あまり書かれていないコードジェンを使っているだけです。 – VTT