Что более эффективно для парсинга Xml, XPath с XmlDocuments, XSLT или Linq?
Указатель NULL - это тот, который указывает на никуда. Когда вы разыскиваете указатель p, вы говорите «дайте мне данные в месте, хранящемся в« p ». Когда p является нулевым указателем, местоположение, хранящееся в p, является nowhere, вы говорите «Дайте мне данные в месте« нигде ». Очевидно, он не может этого сделать, поэтому он выбрасывает NULL pointer exception.
В общем, это потому, что что-то не было правильно инициализировано.
4 ответа
Абсолютный самый быстрый способ запросить XML-документ является самым твердым: запишите метод, который использует XmlReader, чтобы обработать входной поток и иметь его узлы процесса, поскольку он читает их. Это - способ объединить парсинг и запросы в единственную операцию. (Просто использование XPath не делает этого; и XmlDocument и XPathDocument анализируют документ в их методах Загрузки.) Это обычно - только хорошая идея при обработке чрезвычайно больших потоков данных XML.
Все три метода, которые Вы имеете, описывают, работают так же. XSLT имеет много комнаты, чтобы быть самым медленным партии, потому что это позволяет Вам объединить неэффективность XPath с неэффективностью сравнения с шаблонами. XPath и LINQ запрашивают, оба делают по существу то же самое, которое является линейным поиском счетных списков узлов XML. Я ожидал бы, что LINQ будет незначительно быстрее на практике, потому что XPath интерпретируется во времени выполнения, в то время как LINQ интерпретируется во время компиляции.
, Но в целом, как Вы пишете, Ваш запрос собирается оказать намного большее влияние на скорость выполнения, чем, какую технологию Вы используете.
способом записать быстрые запросы против XML-документов является то же, используете ли Вы XPath или LINQ: сформулируйте запрос так, чтобы как можно меньше узлов посетили во время его выполнения. Это не имеет значения, какую технологию Вы используете: запрос, который исследует каждый узел в документе, собирается работать намного медленнее, чем тот, который исследует только маленькое подмножество их. Ваша способность сделать, который более зависит от структуры XML, чем что-либо еще: документ с пригодной для навигации иерархией элементов обычно будет намного быстрее для запросов, чем тот, элементы которого являются всеми детьми элемента документа.
Редактирование:
, В то время как я вполне уверен, я прав, что абсолютный самый быстрый способ запросить XML является самым твердым, реальное самое быстрое (и самый твердый), путь не использует XmlReader; это использует конечный автомат, который непосредственно обрабатывает символы от потока. Как парсинг XML с регулярными выражениями, это обычно - ужасная идея. Но это действительно дает Вам опцию обмена функциями скорости. Решая не обработать те части XML, в котором Вы не нуждаетесь для своего приложения (например, разрешение пространства имен, расширение символьной сущности, и т.д.) можно создать что-то, что будет искать через поток символов быстрее, чем XmlReader, был бы. Я могу думать о приложениях, где это - даже не плохая идея, хотя там я не могу думать о многих.
Работа запросов LinqToXml против контракта IEnumerable... большинство его операций является O (N), потому что они требуют повторения по IEnumerable.
, Если то, с чего Вы запускаете, является строкой, содержащей xml, для работы с нею в Linq, необходимо было бы проанализировать его в полный граф объектов с помощью XElement. Синтаксический анализ , затем выполните итерации по частям его (для фильтрации его, например).
Мое понимание XPath - то, что он отфильтрует при парсинге, который мог быть очень выгодным с точки зрения производительности. Полный граф объектов не должен быть создан.
Я на самом деле не протестировал его, но Linq является, прежде всего, функцией типа генерала компилируемого кода, и таким образом, это должно быть сопоставимо с использованием запросы XPath и XmlDocument.
основное значение 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, не будут проблемой для производительности.