Comments 23
Спасибо за статью, но всегда на всех графиках пишите, в каких единицах измерения (секунды, циклы, итд), и если это сравнение, то указывайте что «меньше/больше — лучше», это сильно облегчит понимание.
Попробуйте для инициализации XmlReader использовать XmlReader.Create, а не XmlTextReader. Не знаю, как на WP7, а на декстопе инстанцируются совершенно разные классы.
XmlReader есть смысл использовать если объём данных большой, иначе выигрыш слишком мал по сравнению с приобретаемой сложностью кода.
doc.SelectNodes("//item") проигрывает LinqToXml только потому что тут в работу вступает XPath парсер/итератор, если обходить все xml nodes документа в цикле и по имени сравнивать производительность будет такая же как у LinqToXml если не больше.
doc.SelectNodes("//item") проигрывает LinqToXml только потому что тут в работу вступает XPath парсер/итератор, если обходить все xml nodes документа в цикле и по имени сравнивать производительность будет такая же как у LinqToXml если не больше.
Может быть, стоило перейти на JSON?
Я пишу парсинг Office Open XML файлов, подскажите пожалуйста, как мне поможет ссылка на статью о сериализации объектов в JSon?
Все зависит от целей и задач. Если Вам действительно необходимо парсить на телефоне эти файлы, то так и быть.
Вот есть фреймворк для работы с JSON-ом в .NET json.codeplex.com/, там хорошая дока с примерами.
Интересное сравнение. Но помимо XML существуют и другие форматы. Например json или Protocol Buffers. А в WP7 можно хранить объекты в изолированом хранилище. Смотрели в их сторону или сразу остановились на XML?
Насколько я помню, перед тем как использовать данные из изолированного хранилища, их прежде туда необходимо как-то добавить (стянуть с интернета, например), разве не так?
А у меня приложение было полностью независимое от интернета, поэтому использовал xml. И то, только для хранения списка элементов.
Также для работы с большим количеством файлов (несколько сот или тысяч), их можно запаковать в zip и потом спокойно прочитать внутри телефона. Вот ссылка на это подробнее www.sharpgis.net/post/2009/04/22/REALLY-small-unzip-utility-for-Silverlight.aspx
А у меня приложение было полностью независимое от интернета, поэтому использовал xml. И то, только для хранения списка элементов.
Также для работы с большим количеством файлов (несколько сот или тысяч), их можно запаковать в zip и потом спокойно прочитать внутри телефона. Вот ссылка на это подробнее www.sharpgis.net/post/2009/04/22/REALLY-small-unzip-utility-for-Silverlight.aspx
Изолированое хранилище можно использовать как угодно вне зависимости от интернета. Вопрос в скорости работы. XML у вас ведь где-то хранится. Вы его парсите каждый раз при запуске программы. Было бы интересно увидеть насколько изменится скорость загрузки данных, если они один раз выгрузятся в изолированое хранилище в виде объектов и будут переиспользоваться. Насколько это быстрее/медленнее загрузки из XML.
А хранить список элементов можно разными способами.
А хранить список элементов можно разными способами.
На самом деле, вопрос сильно зависит от того, что именно вы хотите получить. Работать напрямую с xml? А зачем? Может быть, надо работать с объектом, и его сериализовать/десериализовать? Или что-то третье?
Спасибо! Интересная статья! Интересное сравнение.
Ещё раз убедился в правильности использования linq to xml для работы с xml.
В примере не требуется сложной обработки содержимого xml. Если же работать с xml, как с БД (поиск/обработка данных), то linq покажет себя намного лучше!
Ещё раз убедился в правильности использования linq to xml для работы с xml.
В примере не требуется сложной обработки содержимого xml. Если же работать с xml, как с БД (поиск/обработка данных), то linq покажет себя намного лучше!
Спасибо за статью, буквально на прошлой неделе задался подобным вопросом когда работал с сервисами возвращающими только XML. Вы на него отлично ответили!
Статья была бы гораздо более полезной, если бы были приведены графики потребления памяти. Вот там разница будет куда большей.
Необычное сравнение. Если начать при чтении с помощью XmlReader строить DOM, то результаты сравнения скорее всего будут совершенно другие. Поэтому, не совсем понимаю сей затеи… а LINQ2XML не только быстрее, но и удобнее :)
XmlDocument грузит весь документ в память, что ни есть гуд. Посчитайте сколько всего вы сможете загрузить больших документов (ограничено размером памяти)… Кроме того, если вам не нужны все элементы, а требуется доступ по id — можно значительно ускорить процесс. Именно по этому придумали базы данных и индексы.
К сожалению, реализация MS SQL Compact для Windows Phone Mango оставляет желать лучшего — работает уж очень медленно. В проекте столкнулся с проблемой — на загрузку 100 записей из базы в WP7 уходит 1.5-2 секунды (при этом добавление индекса ускоряет процесс на 15%, не более). Приходится актуальные данные держать в памяти — иначе работать не комфортно.
К сожалению, реализация MS SQL Compact для Windows Phone Mango оставляет желать лучшего — работает уж очень медленно. В проекте столкнулся с проблемой — на загрузку 100 записей из базы в WP7 уходит 1.5-2 секунды (при этом добавление индекса ускоряет процесс на 15%, не более). Приходится актуальные данные держать в памяти — иначе работать не комфортно.
Внезапно, StAX быстрее DOM! В целом выводы-то верные, наверное, но включили бы в статью объяснение различия в этих технологиях, ну и вариант с dom но без XPath.
Sign up to leave a comment.
Производительность: LINQ to XML vs XmlDocument vs XmlReader на Desktop и Windows Phone