問題タブ [memory-footprint]

.a ファイルにコンパイルされたライブラリがあるとしましょう。その後、このライブラリは他のコードとリンクされて実行可能ファイル .exe になります。.a ファイルのサイズは 6Mb ですが、この .exe ファイルのサイズは 3Mb です。これの明らかな説明は、リンカがライブラリから未使用のコードを捨てたことです。私が知りたいのは、最終的な実行可能ファイルでの実際のライブラリのコード フットプリントです。

列用のテーブル、smallint、整数、および2つのfloatがあります。各行の予想メモリは14バイト（2 + 4 + 2 * 4）です。テーブルには約700,000行あります。主キーとインデックスを設定していません。MyIsamタイプは約10MB（各行の平均15b）を必要としますが、InnoDBタイプは30Mb（平均44b）以上を必要とします。ここで何が欠けていますか？InnoDBは各行に非常に多くのオーバーヘッドがあるのでしょうか、それともテーブルのステータス番号は信頼できないのでしょうか。GBに達するデータを保存する必要があるため、さまざまなパラメーターを比較検討してストレージの種類を決定する必要があります。

1. Java アプリケーション内で現在使用されている永続世代 (PermGen) のサイズを測定する方法はありますか? VisualVM などの外部プロファイリング ツールを使用できません。

2. PermGen 内の Java クラスのメモリ消費量を見積もることができればさらに良いでしょう。バイトコードファイルのサイズにほぼ比例しますか?

大規模な Delphi アプリケーションがあり、メモリ フットプリントを低く抑えようとしています。

私のプログラムでは、コンポーネント (Taco) と、taco を継承するコンポーネント (TBurrito) を使用しています。実際のインスタンスではなく、クラスのメモリ使用量に関して、どのシナリオがより多くのメモリを使用するのでしょうか?

A. どこでも TBurrito コンポーネントだけを使用する

また

B. Taco と TBurrito のコンポーネントを組み合わせて使用​​していますか?

私の考えでは、TBurrito は Taco を継承しているため、クラス Taco は既にメモリに格納されているため、それを使用してもメモリのフットプリントはそれほど増加しません。

*注 - コンポーネント名は実際には Taco や Burrito ではありません。

これは、Kプログラミング言語に関するウィキペディアのエントリからの抜粋です。

インタプリタのサイズが小さく、言語の構文がコンパクトなため、K個のアプリケーションをプロセッサのレベル1キャッシュに完全に収めることができます。

特にKプログラムをそれほど小さくしているのは何ですか？'Kの演算子、mapHaskellのようなコンパイルされた関数型言語、またはCのようなコンパイルされた命令型言語の同等のループを使用する場合、コンパイラが根本的に異なるアセンブリコードを生成することや、インタプリタの内部で発生することがループとは大きく異なるforことは想像できません。。Kのランタイムとプログラムを非常に小さくする特別なものはありますか？for

SOについても同様の質問がありますが、そこにある答えは基本的に何も明確にしません。

物理メモリの合計、CPU 使用率、および使用中のメモリ量を取得したいと考えています。を調べましRuntime.freeMemory()たが、それはシステム全体の空きメモリではありません。

パフォーマンスと効率的なメモリ使用量の点で優れているのは次のうちどれですか？

プリミティブ型を使用する方が高速で簡単なはずですが、一方で、静的オブジェクトへの参照を使用する場合、新しい値は作成されません。それとも、コンパイラレベルで最適化されておりtrue、falseメモリを節約するために静的オブジェクトへの参照に置き換えられていますか？

私のWindows上のCアプリケーションは、多数のエントリをデータ構造にダンプし、同じものをxmlに保存するforループを実行しています。今、同じことをするのに必要なメモリフットプリントを知りたいです。利用可能なツールはありますか？

タスク マネージャーによると 130MB のメモリを保持するプロセスがあり、dotTrace によると 11MB のライブ .NET オブジェクトしかないので、他の 120MB で何が起こっているのだろうか??

プロセスに読み込まれたアセンブリとネイティブ DLL を一覧表示し、処理中のイメージのサイズを取得し、アセンブリごとに JIT されたメソッドのメモリ フットプリントを測定するツールが必要です。

SysInternal のListDllsは、その役割の一部を果たします。ただし、JITed コードのサイズは測定されず、生データのみが提供されます。理想的には、これらのデータを分析して集計する UI が必要です。

最近、Visual Studio チームは、ツールPerfViewを使用してそのような分析を行ったことを報告しました。これは、ブログ投稿Visual Studio 11 Beta Performance Part #1のセクション: The Biggest VM Consumer - DLLsに記載されています。PerfView を使用してネイティブ DLL とアセンブリのフットプリントを分析した経験とフィードバックを持っている人はいますか?

ListDllsとPerfViewを除いて、他のツールをお勧めしますか?

わかりました。Simon MourierがアドバイスしたVMMAPは、このタスクにより適したツールのようです。VMMAP は、ワーキング セット メモリの大部分がマネージド スタック (下図の緑色の 113MB) に入ることを示しているため、問題はアンマネージド メモリよりも .NET オブジェクトに関連しています。緑の鋸歯状の曲線は、セッションのロード/アンロードの単なるタイムラインです。いくつかの理由で、私の最初の測定はかなり間違っていました。

• dotTrace は、41MB の .NET オブジェクトが割り当てられていることを示しています。
• WMMAP では 180MB のワーキング セットが表示されます (タスク マネージャーでも同様の数値が表示されます)。
• WMMAP は、GC によって割り当てられた 113 MB のマネージド ヒープを示しています。このマネージ ヒープ メモリの 90 MB はワーキング セットにあります。

だから私の計画は次のとおりです。

1. GC が 41 MB の .NET オブジェクトに 113 MB のマネージド ヒープを割り当てる理由を特定してください。(そのような数値は正常ですか? フラグメンテーションが高いためですか?)
2. 割り当てられた .NET オブジェクトのこの 41MB セットを縮小する作業を行ってください!

次の C プログラム 'pause.c' を考えてみましょう。

このコマンド 'gcc -Os pause.c -o pause' を使用して x64 Linux 3.0.0-16-generic でこれをコンパイルすると、サイズが ~8KB の実行可能ファイルが生成されます。この実行可能ファイルを実行し、'pmap -d PID' を使用して正確なメモリ フットプリントを調べると、プロセスに割り当てられたプライベート メモリが 192KB であることがわかります (通常、システムによって異なり、128KB から 192KB の間で異なります)。

valgrind と massif を使用してプロセスを調べると、メモリ割り当てイベントの検出に失敗します。192KB という数値が正確かどうかは懐疑的でしたが、「一時停止」プロセスの 5 つのインスタンスを開始すると、約 1MB のシステム メモリが消費されることがわかりました。

このメモリの起源を説明するのは途方に暮れています。このメモリが割り当てられている理由と、メモリを減らす可能性のある潜在的なアクションについて、誰かが洞察を提供できますか?