Abus de XmlReader ReadSubtree ()

Question

J'ai besoin d'analyser un fichier XML qui est pratiquement l'image d'une très grande arborescence. J'utilise donc la classe XmlReader pour renseigner l'arbre "à la volée". Chaque nœud reçoit uniquement le bloc XML attendu par son parent via la fonction ReadSubtree (). Cela présente l'avantage de ne pas avoir à s'inquiéter du moment où un nœud a consommé tous ses enfants. Mais maintenant, je me demande si c'est vraiment une bonne idée, car il pourrait y avoir des milliers de nœuds et en lisant les fichiers source .NET, j'ai constaté qu'un couple (et probablement plus) de nouveaux objets sont créés avec chaque appel ReadSubtree, et aucune mise en cache pour les objets réutilisables n'est effectuée (ce que j'avais vu).

Peut-être que ReadSubtree () n'a pas été pensé pour être utilisé massivement, ou peut-être que je ne m'inquiète que pour rien et que je dois juste appeler GC.Collect () après avoir analysé le fichier ...

J'espère que quelqu'un pourra nous éclairer à ce sujet.

Merci d'avance.

Mise à jour:

Merci pour vos réponses intéressantes et perspicaces.

J’ai examiné de plus près le code source .NET et j’ai trouvé qu’il était plus complexe que ce que j’avais imaginé. J'ai finalement abandonné l'idée d'appeler cette fonction dans ce scénario même. Comme Stefan l'a souligné, le lecteur xml n'est jamais transmis à des étrangers et je peux faire confiance au code qui analyse le flux xml (qui est écrit par moi-même). Je préférerais donc que chaque nœud soit responsable de la quantité de données qu'il contient. volez dans le flux plutôt qu'en utilisant la fonction ReadSubtree () pas trop mince en fin de fichier pour enregistrer quelques lignes de code.

Answer 1

ReadSubTree () vous donne un XmlReader qui enveloppe le XmlReader original. Ce nouveau lecteur apparaît aux consommateurs comme un document complet. Cela peut être important si le code que vous transmettez à la sous-arborescence pense qu'il obtient un document XML autonome. Par exemple, la propriété Depth du nouveau Reader commence à 0. C'est un wrapper assez fin, vous n'utiliserez donc pas plus de ressources que si vous utilisiez directement le XmlReader d'origine. Dans l'exemple que vous avez donné, c'est plutôt probable que vous ne tirez pas vraiment grand profit du lecteur de sous-arbre.

Dans votre cas, le gros avantage serait que le lecteur de sous-arborescence ne peut pas lire accidentellement au-delà de la sous-arborescence. Étant donné que le lecteur de sous-arborescence n'est pas très coûteux, cette sécurité peut suffire, bien que cela soit généralement plus utile lorsque vous avez besoin que la sous-arborescence ressemble à un document ou que vous n'ayez pas confiance que le code lise uniquement son propre sous-arborescence. >

Comme le notera Will, vous ne voudrez jamais appeler GC.Collect (). Cela n'améliorera jamais les performances.

Answer 2

En supposant que tous les objets sont créés sur le segment de mémoire géré normal, et non pas dans le segment de grande taille (c'est-à-dire moins de 85 Ko), il ne devrait y avoir aucun problème, c'est exactement ce que le GC a été conçu pour traiter.

Je suggérerais qu’il n’est pas non plus nécessaire d’appeler GC.Collect à la fin du processus, car dans presque tous les cas, permettre au GC de programmer lui-même des collections lui permet de fonctionner de manière optimale (voir cet article de blog pour une explication très détaillée de GC, qui explique cela beaucoup mieux que moi).