Me preguntaba si hay alguna diferencia de rendimiento cuando se utiliza simples consultas como:XPathSelectElement vs Descendientes
var x = document.XPathSelectElement("actors/actor")
vs
var x = document.Descendants("actors").Descendants("actor")
Tenga en cuenta que este
var x = document.Elements("actors").Elements("actor").FirstOrDefault();
es el equivalente de su primera declaración.
Habrá una diferencia de rendimiento, porque los métodos están haciendo cosas muy diferentes bajo el capó. Sin embargo, la optimización de las operaciones puramente en memoria es un poco inútil a menos que se trate de un gran conjunto de datos. Si está tratando con un gran conjunto de datos, entonces debe medir el rendimiento de ambas alternativas en lugar de tratar de predecir cuál se ejecutará más rápido.
Ah, eso es correcto. Exactamente lo que necesitaba saber. ¡Gracias! – Mattias
excepto que trabaja con enormes archivos xml (como 1gig o más grande) - entonces podría querer hacer un benchmark (debería echar un vistazo a cómo escribir un microbenchmark correcto: http://stackoverflow.com/questions/504103/how -do-i-write-a-correct-micro-benchmark-in-java) – user181750
@Christian: ¿Hay alguna evidencia de que usar XPathSelectElement tenga una diferencia de rendimiento "minúscula". No digo que no sea cierto, pero ¿cómo se sabe? La única forma en que podría ser minúsculo es si la expresión XPath resultante se compila y almacena en caché. Eso es cierto de XPath en System.Xml, pero ¿es lo mismo en Linq-To-Xml? ¿Hay alguna documentación o blog de MS Team o algunas pruebas de comparación publicadas en la web que lo confirman? – AnthonyWJones
Sí, aunque las dos líneas no son equivalentes.
El XPath tiene que ser analizado en última instancia, en una expresión LINQ que luego de hacer esto: -
var x = document.Elements("actors").Elements("actor");
Sin embargo es bastante posible que internamente una versión compilada de la expresión XPath se almacena de manera que utilizando sólo un XPath cuesta el tiempo que lleva buscar la cadena en algún diccionario interno. Si eso es realmente el caso o no, no lo sé.
Lectura interesante. ¡Gracias! – Mattias
parece que no es un éxito, alguien más ha hecho el trabajo de evaluación comparativa: http://blog.dreamlabsolutions.com/post/2008/12/04/LINQ-to-XML-and-LINQ-to-XML-with-XPath-performance-review.aspx
Creo que la evaluación comparativa es un poco defectuosa ya que compara "//" expresiones XPath con acceso a descendientes directos. –
Desde mi prueba limitada, el rendimiento parece muy similar. Tomé un mensaje XML de ejemplo de http://msdn.microsoft.com/en-us/library/windows/desktop/ms762271(v=vs.85).aspx
XPath:
/book[id='bk109']
LINQ consulta:
from bookElement in xmlElement.Descendants("book")
where bookElement.Attribute("id").Value == "bk109"
select bookElement
entonces ejecuta cada 10.000 veces (excluyendo el tiempo que tomó para analizar la cadena y la primera ejecutar para eliminar el ruido CLR).
Resultados (100.000 iteraciones)
Por lo tanto, parece que, al menos en algunos casos, la evaluación XPath en XElement tiene un rendimiento mejor que LINQ en XML. Las evaluaciones XPath en XPathDocument son incluso más rápidas.
embargo, parece que la carga de un XPathDocument tarda un poco más largo que la carga de un XDocument (1000 iteraciones):
'XPathDocument' da como resultado un espacio de memoria muy grande para documentos XML no triviales. –
Nota al pie: respuestas a esta pregunta ignorar http://stackoverflow.com/questions/3705020/what-is-the-difference-between- linq-to-xml-descenddants-and-elements - la segunda consulta devolverá nodos como "/ foo/actors/random_nodes/actor" a diferencia del primero que solo devuelve "actor" que es hijo inmediato de "actors". –