5

私が実際に行っていることを期待するよりもはるかに大きなコードを生成する C++ ライブラリがあります。ソースの 50K 行未満から、ほぼ 4 MB の共有オブジェクトと 9 をプッシュする静的アーカイブを取得します。コード サイズで KB。-Os のようなフラグを付けてライブラリをコンパイルすると、これはいくらか助けられますが、実際にはあまり役に立ちません。

また、GCC の -frepo コマンド (私が見たすべてのドキュメントでは、Linux では collect2 が重複したテンプレートをとにかくマージすることを示唆していますが) と、多くの重複が「ありそうな」と思われるテンプレートでの明示的なテンプレートのインスタンス化についても実験しましたが、どちらの場合でも実際の効果。もちろん、私が「可能性が高い」と言ったのは、あらゆる種類のプロファイリングと同様に、このような盲目的な推測はほとんどの場合間違っているからです。

コードサイズのプロファイリングを簡単にするツール、または何がそんなに多くのスペースを占めているかを把握できる他の方法、またはより一般的には、他に試してみるべきことはありますか? Linux で動作するものが理想的ですが、入手できるものを使用します。

4

3 に答える 3

7

実行可能ファイルに何が含まれているかを知りたい場合は、ツールに問い合わせてください。ld リンカの --print-map (または -M) オプションをオンにして、メモリ内の内容と場所を示すマップ ファイルを生成します。静的にリンクされた例でこれを行うと、おそらくより有益です。

ld を直接呼び出すのではなく、gcc コマンド ラインからのみ呼び出す場合は、ld 固有のオプションの前に を付けて、gcc コマンド ラインから ld に渡すことができます-Wl,。

于 2009-10-13T17:56:48.493 に答える
2

Linux では、リンカーは確かに複数のテンプレートのインスタンス化をマージします。

デバッグ バイナリを測定していないことを確認してください (デバッグ情報は、最終的なバイナリ サイズの 75% 以上を占める可能性があります)。

最終的なバイナリ サイズを減らす 1 つの方法は、 と でコンパイルして-ffunction-sectionsから-fdata-sectionsでリンクすること-Wl,--gc-sectionsです。

[gold][1]( binutils の一部である新しい ELF 専用リンカー) の開発バージョンを使用し、-Wl,--icf

もう 1 つの便利なテクニックは、共有ライブラリによって「エクスポート」されるシンボルのセットを減らすことです (デフォルトではすべてがエクスポートされます) __attribute__((visibility(...)))。詳細はこちら（「輸出規制」参照）。

于 2009-10-14T03:12:30.373 に答える
1

非常に粗雑ですが非常に手っ取り早い方法の 1 つは、オブジェクト ファイルのサイズを確認することです。オブジェクト ファイル内のすべてのコードが最終的なバイナリにコンパイルされるわけではないため、いくつかの誤検出が発生する可能性がありますが、ホットスポットがどこにあるのかについて良い印象を与えることができます。最大のオブジェクト ファイルを見つけたら、objdumpや などのツールを使用してそれらを詳しく調べることができますnm。

于 2009-10-13T20:51:57.600 に答える