C# : la méthode close de Xml.Charge(fichier)

J'ai écrit un code qui charge un document XML à l'aide d'un XmlDocument objet, de telle sorte qu'à compter de nœuds. Voici la méthode:

XmlDocument xml = new XmlDocument();
xml.Load(textBox1.Text);
XmlNodeList nodes = xml.SelectNodes("//File");
foreach (XmlNode node in nodes)
{
    number_of_childs++;
}

Le problème que je suis confronté est, lors de l'importation d'un fichier de grande taille, il prend comme 700MO de RAM. Si je puis essayer de faire une opération sur le fichier, ou même de lire afin d'afficher ses données dans un ListView, l'application prend comme 2 go de RAM. Donc, je me demandais, est-il une méthode qui ferme la XmlDocument et libère sa mémoire, de libérer de la RAM. C'est comme oublier d'effacer son contenu à partir de la mémoire.

InformationsquelleAutor R.Vector | 2012-06-13
  1. 15

    Pas. Le XmlDocument classe n'implémente pas IDisposable, donc il n'y a aucun moyen de le forcer à libérer des ressources à volonté. Si vous avez vraiment besoin immédiatement pour libérer la mémoire utilisée par XmlDocument, la seule façon de le faire serait de faire ce qui suit:

    nodes = null;
xml = null;
GC.Collect();

    Le garbage collector fonctionne sur un thread séparé, de sorte qu'il peut tout de même pas se faire immédiatement. À force de la collecte des déchets pour produire de façon synchrone, avant de poursuivre l'exécution de votre code, vous devez également appeler WaitForPendingFinalizers, en tant que tel:

    nodes = null;
xml = null;
GC.Collect();
GC.WaitForPendingFinalizers();

    XmlDocument charge toujours la totalité du document en mémoire à la fois. Si vous voulez simplement parcourir les nœuds dans le document comme un ruisseau, que le chargement un peu à la fois, qu'est ce que le XmlReader classe. Cependant, vous perdez beaucoup de fonctionnalités de cette façon. Par exemple, il n'y a aucun moyen de sélectionner des nœuds via XPath, comme vous, où en train de faire dans votre exemple. Avec XmlReader, vous devez écrire votre propre logique pour déterminer où dans le document que vous êtes et si qui correspond à ce que vous recherchez.

    • Je vous remercie pour cette information , mais il ne fonctionne pas , j'ai appliqué votre morceau de code, mais il réserve encore la même quantité de mémoire.
    • voir mon edit.
    • Ouais , il a travaillé, mais la deuxième étape de l'application est de lire chaque nœud et le type dans une listview , si problème existe toujours , mais si je peux lire chaque node de xml et de les libérer de l'espace de la mémoire lorsqu'elle a été correctement stocké quelque part <<< de cette façon serait mieux pour la gestion de la mémoire.
    • Mon exemple ne faire exactement cela. Si libère la mémoire qui a été utilisée pour charger le XML, mais, évidemment, la vue de la liste de contrôle de toujours utiliser la mémoire pour stocker les données dans les éléments de la liste. Par le chemin, vous rencontrez de graves problèmes de performances avec l'utilisation de la mémoire, ou êtes-vous juste de remarquer la mémoire de monter et il dérange vos sensibilités? Si c'est juste votre sensibilité, vous avez besoin de s'habituer à l'ignorer. Depuis .NET utilise la collecte des ordures, la mémoire de votre application consommation fluctue tous sur la place, apparemment au hasard. C'est normal et attendu. Vous ne devriez pas vous inquiéter à ce sujet
    • Oups. J'ai oublié de définir des nœuds à null dans mon exemple.
    • Merci beaucoup @Steve , il a vraiment aidé à améliorer les performances de l'application concernant l'utilisation de la mémoire , avant que l'amélioration de l'application a été d'environ 2 go de RAM et de s'écraser , mais après amélioration, il prend seulement 1,4 GO

    InformationsquelleAutor Steven Doggart
  2. 2

    Si vous n'avez pas à Manipuler le XML, il suffit de lire le XML à l'aide de XMLReader, qui est unidirectionnelle et le plus rapide, avec moins de mémoire intense opération.

    InformationsquelleAutor Furqan Hameedi
  3. 1

    Il n'est pas nécessaire de régler votre objet à null. Le GC doit être en mesure d'indiquer si le Document n'est pas utilisé sur son propre. Cela se fera automatiquement que la mémoire est nécessaire, mais si vous voulez l'effacer immédiatement appel GC.Collect(). Voir ce fil pour la poursuite des discussions.

    • Je suis d'accord qu'il n'est généralement pas une grande préoccupation, et les GC finira par libérer de la mémoire sur son propre, mais si vous allez appeler le garbage collector manuellement, vous devez définir la variable à null avant d'appeler GC.Recueillir, sinon l'objet sera toujours référencé et il ne sera pas collecté.
    • Doggart, votre énoncé n'est vrai que dans les versions de Débogage. Dans les versions Release, réglage de la valeur null n'est pas nécessaire--le GC est assez intelligent pour voir que ce n'est plus référencé sans paramètre à null. Voir stackoverflow.com/questions/5545288/... par exemple.
    • C'est surprenant et intéressant. Est-ce parce que la Version de publication, par défaut, des optimisations supplémentaires qui seraient automatiquement définissez la variable null dès qu'il n'est plus utilisé, ou quelque chose?
    • Je crois qu'il est juste que la variable est considérée comme n'est plus référencé après sa dernière utilisation. Je ne m'attends pas que la Libération de construire ajoute dans le code de définition de la variable à null. C'est plus que la version debug provoque la référence à exister plus longtemps qu'il serait naturellement pour permettre de regarder cette variable dans un débogueur.
    • Dans l'exemple que vous avez lié à l', Hans a été de dire que, même si la variable est hors de portée, la référence continue d'exister sur la pile lors de Débogage. Je pense que si la variable est toujours dans la portée, la référence existe toujours, même dans le Communiqué.
    • J'ai écrit un petit un petit exemple d'application à l'aide d'une classe avec un Finaliseur avec GC.Collect et GC.WaitForPendingFinalizers qui a montré la différence de comportement entre la Libération et de Débogage. L'exemple d'application a montré que, même si la variable est portée il a obtenu finalisé sans paramètre à null. Je peux vous envoyer l'échantillon si vous êtes intéressé.
    • Très intéressante. Merci pour l'info!
    • Voici l'exemple d'application qui montre les différentes commande entre Debug et Release: codepad.org/zmI3vBlQ.
    • C'est très intéressant, je n'avais aucune idée qu'il n'y a aucune différence, je vous remercie pour cela.

    InformationsquelleAutor Fr33dan