14

C ++プロジェクトに3年間取り組んだ後、実行可能ファイルは4MBに増えました。この空間がどこに向かっているのか見たいです。最大のスペースホッグが何であるかを報告できるツールはありますか？クラス別（クラス内のすべての関数）、テンプレート別（すべてのインスタンス化）、およびライブラリ別（C標準ライブラリとSTLにどれだけ属しているか？exe内の各ライブラリにどれだけあるか？）のサイズを確認すると便利です。

編集：注：私はWindowsでVisualC++を使用しています。

4

5 に答える 5

16

Linux ではnm、実行可能ファイル内のすべてのシンボルを表示し、サイズの逆順で並べ替えるために使用できます。

$ nm -CSr --size-sort <exe>

オプション:

  • -CC++ 名を分解します。
  • -Sシンボルのサイズを示します。
  • --size-sortシンボルをサイズ順に並べ替えます。
  • -rソートを逆にします。

名前空間ごとまたはクラスごとに結果を取得する場合は、' '、' 'などgrepの出力のみを取得できます。namespace::namespace::class_name::

実行可能ファイルで定義されているシンボル(ライブラリのように他の場所で定義されているものではない) のみを表示する場合は、 を追加し--defined-onlyます。ただし、未定義のシンボルにはサイズがないため、サイズによる並べ替えでこれを処理する必要があります。

Windowsの場合、 COFFバイナリがサポートされているnmため、バイナリ ファイルで引き続き使用できるはずです。cygwin 経由でインストールするか、Windows 実行可能ファイルを Linux ボックスにコピーしてそこで実行することができます。nmnmnm

dumpbinWindows 上のバイナリに関する情報をダンプするを試すこともできます。スイッチでシンボルの情報を取得できますが/SYMBOLS、サイズに関する情報を直接提供しているようには見えません。

于 2009-06-26T22:59:28.467 に答える
7

Visual Studio コンパイルの下の Windows では、この情報は .map ファイルにあります (.pdb の近くにあります)。

追加: .map ファイルにある装飾された名前を人間が読める形式に変換するには、Visual Studio に含まれているundname.exeユーティリティを使用できます。コマンドラインで個々の名前を受け入れるか、.map ファイルをフィードできます。

例えば、

Microsoft (R) C++ Name Undecorator
Copyright (C) Microsoft Corporation. All rights reserved.

Undecoration of "?push_back@?$mini_vector@U?$Point@U?$FixedPoint@$0O@H@Math@@@Math@@$05@@QAAXABU?$Point@U?$FixedPoint@$0O@H@Math@@@Math@@@Z" is 

"public: void __cdecl mini_vector<struct Math::Point<struct Math::FixedPoint<14,int> >,6>::push_back(struct Math::Point<struct Math::FixedPoint<14,int> > const &)"
于 2009-06-26T23:20:56.503 に答える
2

私は自分のために仕事をすることができませんでしたが、 Sizernmという便利なツールを見つけることができました。Debug Interface Access ライブラリを使用して、Visual Studio によって作成されたデバッグ情報を読み取ります。サイトで説明されているように、使用するのは非常に簡単です。

  1. プログラム データベース (.pdb) ファイルのデバッグ情報を使用してコンパイルする
  2. コマンドラインから sizer を実行しますSizer.exe <path-to-exe-file>。出力は stdout に送られるため、おそらくファイルにリダイレクトする必要があります。

コード サイズはさまざまなセクションに分類され、関数、データ、クラスなどによってグループ化され、各セクションはコード サイズの降順で並べ替えられます。

于 2013-04-01T12:24:30.420 に答える
1

リンク マップを取得するかdumpbin、シンボルとサイズのリストを取得するために使用します。

厳密には必要のないものが大量に取り込まれている可能性があります。

追加: 満足のいく回答が得られましたか? 私は、人々がこのような問題にアプローチする方法が 2 つあることに気付きました。

  • 彼らが何かをする前に測定値を取得します。
  • 必要のない大きなものを見つけてはぎ取り、できなくなるまで繰り返します。

個人的には後者の方が好きです。結果が早く得られます。

あなたはアプリが4MBだと言います。実際に必要なサイズが 1MB (またはそのようなサイズ) であるとします。つまり、マップ ファイルからルーチンを無作為に選択した場合、75% の確率で必要のないものになる可能性があります。含まれている原因を突き止め、本当に必要かどうかを確認してください。

あなたが示した例では、デバイスに依存しないビットマップをラップするクラスを見ました。アプリでそのクラスのインスタンスを見つけて、基本的な WIN32 ビットマップに置き換えることができます。きれいではありませんが、アプリのサイズを節約できます。

それからそれを続けてください。アプリは縮小されていますが、破片はまだ縮小されていないため、取り除く大きな破片ごとに、残りの破片がアプリのより大きな割合を占めるようになります。これにより、マップ ファイル内でそれらを見つけやすくなります。

于 2009-06-26T23:16:32.130 に答える
1

コードだけを見ないでください。リソースは簡単に数メガバイトの増加を引き起こす可能性があります。

于 2009-06-26T23:23:48.510 に答える