13

大規模な C++ プロジェクト (VC6) のリンカー マップ ファイルの分析を簡素化するツールを探しています。

メンテナンス中、バイナリは着実に成長しており、それがどこから来たのかを突き止めたいと思っています。異なる DLL 間で共有されているライブラリ内の過度のテンプレート展開が疑われますが、マップ ファイルを参照しても良い手がかりは得られません。

助言がありますか？

4

5 に答える 5

16

これは素晴らしいコンパイラ生成マップ ファイル分析/エクスプローラ/ビューア ツールです。gcc で生成されたマップ ファイルを探索できるかどうかを確認します。

amap : 32 ビット Visual Studio コンパイラによって生成された .MAP ファイルを分析し、データとコードによって使用されているメモリの量を報告するツール。このアプリは、Xbox360、Wii、および PS3 コンパイラによって生成された MAP ファイルを読み取って分析することもできます。

于 2012-09-19T11:09:32.323 に答える
2

マップ ファイルには各セクションのサイズが必要です。このサイズでシンボルを並べ替える簡単なツールを作成できます。また、MSVC に付属するコマンド ライン ツール (undname.exe) を使用してシンボルをデマングルすることもできます。

シンボルをサイズで並べ替えたら、これを毎週または毎日生成して、各シンボルのサイズが時間の経過とともにどのように変化したかを比較できます。

1 つのビルドからのマップ ファイルだけではあまりわかりませんが、コンパイルされたマップ ファイルの履歴レポートからはかなりのことがわかります。

于 2009-02-23T18:42:40.427 に答える
1

ツールの提案はありませんが、考えられる原因についての推測: インクリメンタル リンクを有効にしていますか? これにより、後続のビルド中に拡張が発生する可能性があります...

/opt:ref を使用してコンパイルしている場合、リンカーは未使用のシンボルを削除します。そのため、インクリメンタル リンクを使用せずにそれを使用している場合、バイナリの展開は実際の新しいコードが追加された結果にすぎないと予想されます。それは私が知る限りです...それが少し役立つことを願っています.

于 2009-02-23T18:33:03.677 に答える
0

テンプレート、マクロ、STL などはすべて、膨大な量のスペースを使用します。優れたユニバーサル ライブラリとして知られる BOOST は、プロジェクトに多くのスペースを追加します。BOOST_FOR_EACH はこの例です。何百行ものテンプレート化されたコードは、適切なループ ハンドルを作成することで簡単に回避できますが、通常はキー ストロークを数回追加するだけです。

テンプレートを使用するのではなく、入力を節約する Visual AssistX を入手してください。また、使用するコードを所有することも検討してください。マクロとインライン関数展開は、必ずしも表示されるわけではありません。

また、可能であれば、DLL アーキテクチャから離れて、さまざまな「モード」で実行される 1 つの実行可能ファイルにすべてを静的にリンクするようにします。実行したい内容に応じて異なるコマンド ライン パラメータを渡すだけで、同じ実行可能イメージを何度でも使用しても問題はありません。

DLL は、スペースを浪費し、プロジェクトの実行時間を遅くする最悪の原因です。人々は自分のことを省スペースだと思っていますが、実際には逆の結果になりがちで、プロジェクトのサイズが 10 倍になることもあります。さらに、スワッピングが増加します。パフォーマンスのために、固定コード セクション (再配置セクションなし) を使用します。

于 2010-12-16T13:19:25.573 に答える