La forma más rápida y absoluta de consultar un documento XML es la más difícil: escriba un método que use un XmlReader para procesar la secuencia de entrada y haga que procese los nodos a medida que los lee. Esta es la forma de combinar el análisis y la consulta en una sola operación. (El simple hecho de usar XPath no hace esto, tanto XmlDocument como XPathDocument analizan el documento en sus métodos de carga). Esta suele ser una buena idea si está procesando flujos de datos XML extremadamente grandes.
Los tres métodos que ha descrito funcionan de manera similar. XSLT tiene mucho espacio para ser el más lento del lote, porque le permite combinar las ineficiencias de XPath con las ineficiencias de la coincidencia de plantillas. Las consultas XPath y LINQ hacen esencialmente lo mismo, que es una búsqueda lineal a través de listas enumerables de nodos XML. Esperaría que LINQ sea marginalmente más rápido en la práctica porque XPath se interpreta en tiempo de ejecución mientras LINQ se interpreta en tiempo de compilación.
Pero, en general, la forma de escribir la consulta va a tener un impacto mucho mayor en la velocidad de ejecución de lo que la tecnología que utiliza.
La forma de escribir consultas rápidas contra documentos XML es la misma ya sea que esté utilizando XPath o LINQ: formule la consulta para que se visiten la menor cantidad posible de nodos durante su ejecución. No importa qué tecnología utilice: una consulta que examine todos los nodos del documento se ejecutará mucho más lentamente que una que solo examine un pequeño subconjunto de ellos. Su capacidad para hacerlo depende más de la estructura del XML que de cualquier otra cosa: un documento con una jerarquía de elementos navegables generalmente será mucho más rápido de consultar que uno cuyos elementos son todos elementos secundarios del elemento del documento.
Editar:
Aunque estoy bastante seguro de que tengo razón de que la manera más rápida absoluta para consultar un XML es el más duro, la verdadera manera más rápida (y más difícil) no utiliza un XmlReader; usa una máquina de estado que procesa directamente los caracteres de una secuencia. Al igual que analizar XML con expresiones regulares, esta es generalmente una idea terrible. Pero te da la opción de intercambiar funciones por velocidad. Al decidir no manejar las piezas de XML que no necesita para su aplicación (por ejemplo, resolución de espacio de nombres, expansión de entidades de caracteres, etc.) puede construir algo que busque a través de una secuencia de caracteres más rápido que un XmlReader. Puedo pensar en aplicaciones donde ni siquiera es una mala idea, aunque no puedo pensar en muchas.
Vea también http://stackoverflow.com/questions/407350/how-best-to-use-xpath-with-verylarge-xml-files-in-c/716659#716659, en el que señalo al lector XPathReader que combina la velocidad de XmlReader con la facilidad de uso de XPath –
XPathReader es una idea realmente sobresaliente que desconocía por completo. Gracias por señalarme. –
La disponibilidad de PLINQ (Parallel Linq) en .NET 4.0 hace que Linq sea una opción aún más atractiva que antes. Para ser justos, PLINQ realmente está lanzando más caballos de fuerza al problema; no está haciendo que el analizador sea más eficiente. Pero en general Linq logra un buen equilibrio entre brevedad y rendimiento. –