Производительность: LINQ to XML vs XmlDocument vs XmlReader на Desktop и Windows Phone

[atd]

Спасибо за статью, но всегда на всех графиках пишите, в каких единицах измерения (секунды, циклы, итд), и если это сравнение, то указывайте что «меньше/больше — лучше», это сильно облегчит понимание.

[StanEgo]

Попробуйте для инициализации XmlReader использовать XmlReader.Create, а не XmlTextReader. Не знаю, как на WP7, а на декстопе инстанцируются совершенно разные классы.

[azhidkov]

Не знал, домой приеду попробую, спасибо!

[alex_rus]

XmlReader есть смысл использовать если объём данных большой, иначе выигрыш слишком мал по сравнению с приобретаемой сложностью кода.

doc.SelectNodes("//item") проигрывает LinqToXml только потому что тут в работу вступает XPath парсер/итератор, если обходить все xml nodes документа в цикле и по имени сравнивать производительность будет такая же как у LinqToXml если не больше.

[akzhan]

Может быть, стоило перейти на JSON?

[andreyK]

Я пишу парсинг Office Open XML файлов, подскажите пожалуйста, как мне поможет ссылка на статью о сериализации объектов в JSon?

[akzhan]

Все зависит от целей и задач. Если Вам действительно необходимо парсить на телефоне эти файлы, то так и быть.

[akzhan]

Возможно, Вы не поняли моей мысли. В некоторых случаях парсинг XML можно перенести на серверную или настольную сторону. И отдавать в телефон уже преобразованное, легкое, представление.

[vdmitriyev]

Вот есть фреймворк для работы с JSON-ом в .NET json.codeplex.com/, там хорошая дока с примерами.

[andreyK]

Зачем мне framework для работы с JSon, если я пытаюсь прочитать XML файлы???

[vdmitriyev]

Резонно, видимо не до конца понял словообразование в вашей фразе, уж извините.

[plsc_Rover]

Интересное сравнение. Но помимо XML существуют и другие форматы. Например json или Protocol Buffers. А в WP7 можно хранить объекты в изолированом хранилище. Смотрели в их сторону или сразу остановились на XML?

[azhidkov]

Насколько я помню, перед тем как использовать данные из изолированного хранилища, их прежде туда необходимо как-то добавить (стянуть с интернета, например), разве не так?

А у меня приложение было полностью независимое от интернета, поэтому использовал xml. И то, только для хранения списка элементов.

Также для работы с большим количеством файлов (несколько сот или тысяч), их можно запаковать в zip и потом спокойно прочитать внутри телефона. Вот ссылка на это подробнее www.sharpgis.net/post/2009/04/22/REALLY-small-unzip-utility-for-Silverlight.aspx

[plsc_Rover]

Изолированое хранилище можно использовать как угодно вне зависимости от интернета. Вопрос в скорости работы. XML у вас ведь где-то хранится. Вы его парсите каждый раз при запуске программы. Было бы интересно увидеть насколько изменится скорость загрузки данных, если они один раз выгрузятся в изолированое хранилище в виде объектов и будут переиспользоваться. Насколько это быстрее/медленнее загрузки из XML.

А хранить список элементов можно разными способами.

[lair]

На самом деле, вопрос сильно зависит от того, что именно вы хотите получить. Работать напрямую с xml? А зачем? Может быть, надо работать с объектом, и его сериализовать/десериализовать? Или что-то третье?

[valchel]

Спасибо! Интересная статья! Интересное сравнение.

Ещё раз убедился в правильности использования linq to xml для работы с xml.

В примере не требуется сложной обработки содержимого xml. Если же работать с xml, как с БД (поиск/обработка данных), то linq покажет себя намного лучше!

[Seekeer]

>Если же работать с xml, как с БД (поиск/обработка данных), то linq покажет себя намного лучше!
А чем был мотивирован выбор именно XML если нужно с ним работать как с БД? Не проще ли было использовать нормальную БД?

[valchel]

имелось в виду не использование xml в качестве БД, а поиск и обработка данных в нем наподобие БД.

Например, при обмене данными между приложениями.
В качестве БД как таковой я бы тоже не стал его использовать.

[vdmitriyev]

Спасибо за статью, буквально на прошлой неделе задался подобным вопросом когда работал с сервисами возвращающими только XML. Вы на него отлично ответили!

[dmitry_vk]

Статья была бы гораздо более полезной, если бы были приведены графики потребления памяти. Вот там разница будет куда большей.

[posledam]

Необычное сравнение. Если начать при чтении с помощью XmlReader строить DOM, то результаты сравнения скорее всего будут совершенно другие. Поэтому, не совсем понимаю сей затеи… а LINQ2XML не только быстрее, но и удобнее :)

[codecity]

XmlDocument грузит весь документ в память, что ни есть гуд. Посчитайте сколько всего вы сможете загрузить больших документов (ограничено размером памяти)… Кроме того, если вам не нужны все элементы, а требуется доступ по id — можно значительно ускорить процесс. Именно по этому придумали базы данных и индексы.

К сожалению, реализация MS SQL Compact для Windows Phone Mango оставляет желать лучшего — работает уж очень медленно. В проекте столкнулся с проблемой — на загрузку 100 записей из базы в WP7 уходит 1.5-2 секунды (при этом добавление индекса ускоряет процесс на 15%, не более). Приходится актуальные данные держать в памяти — иначе работать не комфортно.

[tulskiy]

Внезапно, StAX быстрее DOM! В целом выводы-то верные, наверное, но включили бы в статью объяснение различия в этих технологиях, ну и вариант с dom но без XPath.