Si hago¿XPathDocument carga todo el documento xml?
XPathDocument doc = new XPathDocument("filename.xml");
¿Eso carga todo el documento en la memoria? Estoy escribiendo una aplicación para teléfono móvil y es posible que el documento almacene muchos datos que no necesitan ser cargados al mismo tiempo. ¡Los teléfonos móviles usualmente no tienen demasiado ram!
Sí, todo el documento XML se representa en la memoria.
Una solución es dividir un documento XML grande en muchos más pequeños.
O, como alternativa, puede escribir su propio XmlReader que ignorará los subárboles no deseados. Puede pasar este XmlReader como argumento al constructor XpathDocument() - necesita camuflarlo como TextReader.
¿Hay alguna forma mejor de cargar ciertas partes de un documento xml? ¿Como solo ciertas etiquetas? – Wires
@wires: No es una solución de sistema, pero puede escribir su propio XmlReader que ignorará los subárboles no deseados. Puede pasar este XmlReader como argumento al constructor XpathDocument() - necesita camuflarlo como TextReader. :) –
https://msdn.microsoft.com/en-us/library/system.xml.xpath.xpathdocument.aspx
"Proporciona una forma rápida, de sólo lectura, en memoria representación de un documento XML utilizando el modelo de datos XPath."
Es posible que desee probar el otro constructor XPathDocument(stream). Transmitir el documento no usará tanta memoria.
Quizás desee echar un vistazo a Linq to XML, ya que es más fácil, más rápido codificar y crear un código más bonito que utilizar el análisis SAX/DOM. Ver esta publicación: How to Store data without using Database and how to retrieve them?
El uso del constructor Stream no tiene ningún efecto en la cantidad de memoria que usará XPathDocument. Y Linq a XML no es más rápido que SAX (o usa un XmlReader, que es el que se usa en .NET en lugar de SAX), ni tampoco, a diferencia del uso de XmlReader, evita leer todo el documento en la memoria. –
En cuanto al constructor de flujo, es por eso que he escrito "es posible que desee". Por otro lado, creo que debería echar un vistazo a cómo Linq transmite los datos y no carga un archivo completo en la memoria. – ALOToverflow
La clase XStreamingElement puede escribir un documento XML muy grande sin crear un documento XML completo en memoria. Pero no se usa para leer. Cuando la mayoría de la gente habla de Linq a XML (como en los dos ejemplos a los que se ha vinculado), están hablando de XDocument y, de hecho, XDocument carga todo el documento XML en la memoria. ¿Hay algún objeto impresionante Linq que estoy pasando por alto? Créame, esto es algo sobre lo que me gustaría equivocarme. –
Es probable que desee algo más como el System.Xml.XmlReader.
Es posible que desee ver el XStreamingElement de LINQ to XML:
Representa elementos en un árbol XML que soporta salida de volcado diferido.
Esta clase le permite crear un árbol XML que admite la transmisión diferida de salida. Utilice esta clase para crear un árbol XML de una manera muy similar para crear un árbol XML usando XElement. Sin embargo, existe una diferencia fundamental . Cuando se utiliza una consulta LINQ para especificar el contenido cuando crear un árbol XML utilizando XElement, la variable de consulta se repite en el momento de construcción del árbol XML, y los resultados de la consulta se añaden al árbol XML . Por el contrario, cuando crea un árbol XML utilizando XStreamingElement, se almacena una referencia a la variable de consulta en el árbol XML sin iterar. Las consultas se repiten solo después de la serialización. Esto le permite crear árboles XML más grandes mientras mantiene una huella de memoria más pequeña.
Si se transmite desde una fuente de entrada , como un archivo de texto, entonces puede leer un archivo de texto muy grande, y generar un documento XML muy grande mientras se mantiene una pequeña memoria huella.
interesante, un C# runtime para un teléfono móvil. – Anurag