Я проанализировал XML, используя оба следующих метода:
Но я никогда не использовал...
Может ли кто-нибудь сказать мне сравнительную эффективность между тремя альтернативами?
Я понимаю, что конкретное использование будет фактором, но мне просто нужна грубая идея. Например, параметр Linq будет значительно медленнее других?
Самый быстрый способ запроса XML-документа является самым сложным: напишите метод, который использует XmlReader для обработки входного потока, и попросите его обработать узлы по мере их чтения. Это способ комбинирования парсинга и запросов в одну операцию. (Просто использование XPath этого не делает, и XmlDocument, и XPathDocument анализируют документ в методах загрузки.) Обычно это хорошая идея, если вы обрабатываете чрезвычайно большие потоки данных XML.
Все три метода, которые вы описали, выполняются аналогичным образом. XSLT имеет много места, чтобы быть самой медленной из партии, потому что это позволяет объединить неэффективность XPath с неэффективностью соответствия шаблонов. Запросы XPath и LINQ выполняют по существу одно и то же, что является линейным поиском через перечислимые списки узлов XML. Я ожидал бы, что LINQ будет на самом деле более быстрым на практике, потому что XPath интерпретируется во время выполнения, в то время как LINQ интерпретируется во время компиляции.
Но в целом, как вы пишете свой запрос, будет иметь гораздо большее влияние на скорость выполнения, чем на используемую вами технологию.
Способ записи быстрых запросов к документам XML одинаковый, независимо от того, используете ли вы XPath или LINQ: сформулируйте запрос так, чтобы как можно большее количество узлов было посещено во время его выполнения. Неважно, какую технологию вы используете: запрос, который проверяет каждый node в документе, будет работать намного медленнее, чем тот, который анализирует только небольшое подмножество из них. Ваша способность делать это в большей степени зависит от структуры XML, чем что-либо еще: документ с навигационной иерархией элементов, как правило, будет намного быстрее запрашивать, чем тот, чьими элементами являются все дочерние элементы документа.
Edit:
Хотя я уверен, что я прав, что самый быстрый способ запросить XML является самым сложным, самый быстрый (и самый жесткий) способ не использует XmlReader; он использует машину состояний, которая непосредственно обрабатывает символы из потока. Подобно анализу XML с регулярными выражениями, это, как правило, ужасная идея. Но это дает вам возможность обмениваться функциями для скорости. Принимая решение не обрабатывать те фрагменты XML, которые вам не нужны для вашего приложения (например, разрешение пространства имен, расширение объектов символов и т.д.), Вы можете построить что-то, что будет искать через поток символов быстрее, чем XmlReader, Я могу придумать приложения, где это даже не плохая идея, хотя там я не могу придумать много.
Запросы LinqToXml работают против контракта IEnumerable... большинство его операций - O (N), потому что они требуют итерации над IEnumerable.
Если вы начинаете с строки, содержащей xml, чтобы работать с ней в Linq, вам нужно проанализировать ее на полный граф объектов, используя XElement.Parse, затем перебирайте его части (например, для фильтрации).
Мое понимание XPath заключается в том, что он будет фильтровать при разборе, что может быть очень выгодным с точки зрения производительности. Полный граф объектов не нужно строить.
Я на самом деле не тестировал его, но Linq - это прежде всего функция типа кода компилятора, и поэтому он должен быть сопоставим с использованием запросов XmlDocument и XPath.
Основное значение Linq заключается в том, что оно обеспечивает проверку результатов ваших запросов, которые не могут предоставить ни XPath, ни XSLT.
Я бы подумал, что если производительность является проблемой, ваше решение будет основано на задаче. Например, получение одного значения из XML-документа может быть самым быстрым с использованием одного запроса XPath, но перевод XML-данных на HTML-страницу будет быстрее с использованием XSLT.
Если вам нужна очень быстрая обработка XML (чтение), вам следует рассмотреть возможность использования XmlReader, к сожалению, реализация немного сложна.
Существует также способ реализовать решение LINQ с комбинацией XmlReader, чтобы вы могли легко использовать LINQ. Также вы можете получить гораздо лучшую производительность, чем XmlDocument/XPath.
Для получения дополнительной информации см. следующую ссылку. http://blogs.msdn.com/xmlteam/archive/2007/03/24/streaming-with-linq-to-xml-part-2.aspx
Также я думаю, что если вы работаете только с маленькими XML файлами, использование XmlDocument/XPath не будет проблемой производительности.