Si jeUn document XPathDocument charge-t-il le document XML entier?
XPathDocument doc = new XPathDocument("filename.xml");
Est-ce que cette charge le document entier en mémoire? J'écris une application de téléphone portable et le document peut stocker beaucoup de données qui n'ont jamais besoin d'être chargées en même temps. Les téléphones mobiles n'ont généralement pas trop de RAM!
Oui, le document XML entier est représenté dans la mémoire.
Une solution consiste à diviser un grand document XML en plusieurs plus petits. Vous pouvez également écrire votre propre XmlReader qui ignorera les sous-arbres indésirables. Vous pouvez passer ce XmlReader comme argument au constructeur XpathDocument() - besoin de le camoufler comme TextReader.
Existe-t-il un meilleur moyen de charger certaines parties d'un document XML? Comme juste certains tags? – Wires
@wires: Pas une solution système, mais vous pouvez écrire votre propre XmlReader qui ignorera les sous-arbres indésirables. Vous pouvez passer ce XmlReader comme argument au constructeur XpathDocument() - besoin de le camoufler comme TextReader. :) –
https://msdn.microsoft.com/en-us/library/system.xml.xpath.xpathdocument.aspx
« Fournit un moyen rapide, en lecture seule, représentation en mémoire d'un document XML en utilisant le modèle de données XPath. »
Vous pouvez essayer l'autre constructeur XPathDocument(stream). La diffusion du document n'utilisera pas autant de mémoire.
Peut-être que vous ne voulez pas regarder Linq to XML, car il est plus facile, plus rapide de coder et de faire du code plus beau que d'utiliser l'analyse SAX/DOM. Voir ce message: How to Store data without using Database and how to retrieve them?
L'utilisation du constructeur de flux n'a aucun effet sur la quantité de mémoire utilisée par XPathDocument. Linq to XML n'est pas plus rapide que SAX (ou utilise XmlReader, ce qui est utilisé dans .NET au lieu de SAX), ni, contrairement à XmlReader, évite de lire tout le document en mémoire. –
En ce qui concerne le constructeur de flux, c'est pourquoi j'ai écrit "vous pourriez vouloir". D'un autre côté, je pense que vous devriez regarder comment Linq diffuse les données et ne charge pas un fichier complet en mémoire. – ALOToverflow
La classe XStreamingElement peut écrire un document XML très volumineux sans créer un document XML entier en mémoire. Mais ce n'est pas utilisé pour lire. Lorsque la plupart des gens parlent de Linq en XML (comme dans les deux exemples auxquels vous avez lié), ils parlent de XDocument, et XDocument charge en fait tout le document XML en mémoire. Y a-t-il un bel objet Linq que je suis en train de négliger? Croyez-moi, c'est quelque chose que j'aimerais bien avoir tort. –
Vous voulez probablement quelque chose de plus comme le System.Xml.XmlReader.
Vous pouvez regarder le XStreamingElement de LINQ to XML:
représente des éléments dans un arbre XML qui prend en charge la sortie de streaming différé.
Cette classe vous permet de créer une arborescence XML prenant en charge la sortie de diffusion différée . Vous utilisez cette classe pour créer un arbre XML d'une manière très similaire pour créer un arbre XML en utilisant XElement. Cependant, il existe une différence fondamentale entre . Lorsque vous utilisez une requête LINQ pour spécifier le contenu lors la création d'un arbre XML à l'aide XElement, la variable de requête est réitérée au moment de construction de l'arbre XML, et les résultats de la requête sont ajoutés à l'arbre XML . En revanche, lorsque vous créez un arbre XML en utilisant XStreamingElement, une référence à la variable de requête est stockée dans l'arborescence XML sans être répétée. Les requêtes ne sont réitérées que lors de la sérialisation. Cela vous permet de créer des arbres XML plus grands tout en conservant une plus petite empreinte mémoire de .
Si vous diffusez à partir d'une source, comme un fichier texte d'entrée , vous pouvez lire un fichier texte très important, et générer un document XML très grand tout en maintenant un faible encombrement mémoire .
intéressant, une exécution C# pour un téléphone mobile. – Anurag