多くの静的分析ツールは、テンプレートのインスタンス化、ヘッダーのインクルード(プリコンパイル済みヘッダーによってプルされるものを含む)、コンパイラーのコード生成特性などを必ずしも考慮していないため、必要なものが得られない可能性があると思います。
私は過去に同様の問題に直面しました。そのサイズが特定のライブラリによって支配されている大きな実行可能ファイルです。私がその根底にたどり着いた方法は、単に各.cppのオブジェクトファイルのサイズを調べることでした。リンカが未使用の部分を最適化するため、完全なストーリーは得られません(ただし/OPT:REF
、Visual Studio用にそのオプションが設定されていることを確認する価値があります)。ただし、検索に集中することができます。2つまたは3つの最大のオブジェクトファイルを見つけて、対応する.cppファイルを確認します。次に、2つのオプションがあります。モジュール内の各関数のオフセットを抽出できるobjdump
(VisualStudio)または(gcc)の出力を取得するスクリプトを記述します。これにより、それぞれを前の関数と比較して、nm -C
各関数のサイズ。
または、最も簡単な方法は、cppファイルでバイナリ検索を使用することです。#includesの終了後にすべてのコードを#ifdefしてコンパイルします。これにより、インクルードのオーバーヘッドがわかります(それ自体が大きい場合は、ヘッダーインクルージョンにドリルダウンして、最も貢献しているものを見つけることができます)。次に、#ifdefを使用してコードの各半分を無効にし、どちらの半分が大きいかを見つけます。この方法を使用すると、ライブラリのサイズに最も寄与する関数をすばやく見つけることができます。
これと同じ問題を抱えていた私が持っていたライブラリの場合、原因は、メンバー変数が保存されるたびにインスタンス化される非常に大きなテンプレート関数であることが判明しました。その場合の解決策は、関数を具体的にして、型固有の動作を必要としないすべてのコードが1回だけインスタンス化され、テンプレート関数が型固有のロジックのビットにローカライズされるようにすることでした。