XmlReader ReadSubtree() の悪用

Question

実際には非常に大きなツリー構造のイメージである XML ファイルを解析する必要があるため、XmlReader クラスを使用して「その場で」ツリーにデータを設定しています。各ノードには、ReadSubtree() 関数を介して親から期待する XML チャンクだけが渡されます。これには、ノードがそのすべての子をいつ消費するかを心配する必要がないという利点があります。しかし今、これが実際に良いアイデアなのかどうか疑問に思っています。何千ものノードが存在する可能性があり、.NET ソース ファイルを読んでいると、ReadSubtree 呼び出しごとにいくつか (おそらくはそれ以上) の新しいオブジェクトが作成されることがわかりました。そして、再利用可能なオブジェクトのキャッシュは行われません（私が見たことがあります）。

おそらく ReadSubtree() が大量に使用されるとは考えられていなかったか、あるいは単に無駄に心配していて、ファイルを解析した後に GC.Collect() を呼び出す必要があるだけかもしれません...

誰かがこれに光を当ててくれることを願っています。

前もって感謝します。

アップデート：

素晴らしく洞察力に富んだ回答をありがとう。

.NET ソース コードを詳しく調べたところ、最初に想像していたよりも複雑であることがわかりました。私はついに、まさにこのシナリオでこの関数を呼び出すという考えを放棄しました。Stefan が指摘したように、XML リーダーが部外者に渡されることは決してなく、XML ストリームを解析するコード (自分で書いたもの) は信頼できるので、各ノードにデータ量に対する責任を負わせるほうがよいでしょう。それほど薄くない ReadSubtree() 関数を使用して数行のコードを節約するよりも、ストリームから盗むことができます。

Answer 1

ReadSubTree() は、元の XmlReader をラップする XmlReader を提供します。この新しいリーダーは、消費者にとって完全な文書として表示されます。これは、サブツリーを渡すコードがスタンドアロンの XML ドキュメントを取得していると考える場合に重要になる可能性があります。たとえば、新しい Reader の Depth プロパティは 0 から始まります。これはかなり薄いラッパーであるため、元の XmlReader を直接使用した場合よりも多くのリソースを使用することはありません。指定した例では、サブツリーから実際にはあまり得られていない可能性があります。読者。

あなたの場合の大きな利点は、サブツリーリーダーが誤ってサブツリーを超えて読み取ることができないことです。サブツリー リーダーはそれほど高価ではないため、その安全性で十分かもしれませんが、サブツリーをドキュメントのように見せる必要がある場合や、コードが独自のサブツリーのみを読み取ることを信頼できない場合には、一般的にはより役立ちます。

Will が指摘したように、GC.Collect() を呼び出す必要はありません。それは決してパフォーマンスを向上させることはありません。

Answer 2

すべてのオブジェクトがラージ オブジェクト ヒープ (つまり、85k 未満) ではなく、通常のマネージド ヒープ上に作成されると仮定すると、実際には問題はありません。これは、GC が対処するように設計されたものにすぎません。

プロセスの最後に GC.Collect を呼び出す必要もないことをお勧めします。ほとんどの場合、GC 自体がコレクションをスケジュールできるようにすることで、GC が最適な方法で動作できるようになります (「 このブログ投稿 GC の非常に詳細な説明があり、私よりもはるかによく説明されています)。