要するに、見積もりを開始する前に静的データを収集するための同様のファイルが常にある場合を除いて、できません。
タグ、属性、接頭辞、名前空間の文字列はインターンされているため、ストレージの効率は XML ファイルの構造に大きく依存し、ディスク上のファイルと比較した比率は、使用するエンコーディングにも依存します。
一般に、.NET はすべての文字列を UTF16 としてメモリに格納します。したがって、大きな構造上のオーバーヘッドがなくても (ルート タグが 1 つしかなく、その中に多数のプレーン テキストが含まれる XML ファイルを想像してください)、UTF8 ソース ファイル (または ASCII またはその他の 8-ビットエンコーディング）が使用されます。したがって、文字列のエンコードは方程式の最初の部分です。
もう 1 つのことは、ドキュメントを効率的にトラバーサルできるように、データ構造がメモリ内に構築されることです。通常、ノードは作成され、参照とともにリンクされます。したがって、各ノードは一定量のメモリを使い果たします。ほとんどの非値データは参照であるため、ここで使用されるメモリもアーキテクチャに大きく依存します (64 ビットでは、1 つの参照に対して 32 ビット システムの 2 倍のメモリが使用されます)。そのため、データがほとんどない非常に複雑なドキュメント (たとえば、テキストや属性値がほとんどないいくつかの異なるタグがたくさんある) がある場合、メモリ使用量は元のドキュメント サイズよりもはるかに多くなり、これはファイルのサイズにも大きく依存します。アプリケーションが実行されるアーキテクチャ。
非常に長いタグ名と属性名がほとんどなく、おそらくデフォルトの名前空間の使用量が多いファイルがある場合、使用されるメモリもディスク上のファイルよりもはるかに少なくなる可能性があります。
そのため、エンコーディングが不明で、妥当な量のデータと複雑さを持つ任意の XML ファイルを想定すると、信頼できる見積もりを得るのは非常に困難です。ただし、言及されている点で XML ファイルが常に類似している場合は、いくつかの統計を作成して、特定のプラットフォームに適した比率を取得する要因を取得できます。
ただし、タスク マネージャーで「空きメモリ」を見たり、「非常に低いメモリ レベル」について話したりすることは、非常にあいまいな定量化であることに注意してください。仮想メモリ、キャッシュ、バックグラウンド アプリケーションおよびサービスなどは、効果的な生メモリの可用性に影響します。したがって、.NET Framework は、1 つのプロセスのパフォーマンスを維持するために、または OutOfMemoryException を安全にスローする前に、使用できるメモリの量を確実に推測できません。そのため、これらの例外のいずれかを受け取った場合、通常はアプリケーションの回復ポイントをはるかに超えているため、それらの例外をキャッチして処理しようとしないでください。