4

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

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

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

前もって感謝します。

アップデート：

素晴らしく洞察に満ちた回答をありがとう。

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

4

2 に答える 2

10

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

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

後で説明するように、GC.Collect（）を呼び出す必要はありません。パフォーマンスが向上することはありません。

于 2008-09-22T11:58:22.527 に答える
2

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

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

于 2008-09-22T12:05:48.627 に答える