Comments 23
Спасибо за статью, но всегда на всех графиках пишите, в каких единицах измерения (секунды, циклы, итд), и если это сравнение, то указывайте что «меньше/больше — лучше», это сильно облегчит понимание.
+1
Попробуйте для инициализации XmlReader использовать XmlReader.Create, а не XmlTextReader. Не знаю, как на WP7, а на декстопе инстанцируются совершенно разные классы.
0
XmlReader есть смысл использовать если объём данных большой, иначе выигрыш слишком мал по сравнению с приобретаемой сложностью кода.
doc.SelectNodes("//item") проигрывает LinqToXml только потому что тут в работу вступает XPath парсер/итератор, если обходить все xml nodes документа в цикле и по имени сравнивать производительность будет такая же как у LinqToXml если не больше.
doc.SelectNodes("//item") проигрывает LinqToXml только потому что тут в работу вступает XPath парсер/итератор, если обходить все xml nodes документа в цикле и по имени сравнивать производительность будет такая же как у LinqToXml если не больше.
+5
Я пишу парсинг Office Open XML файлов, подскажите пожалуйста, как мне поможет ссылка на статью о сериализации объектов в JSon?
+9
Все зависит от целей и задач. Если Вам действительно необходимо парсить на телефоне эти файлы, то так и быть.
-5
Вот есть фреймворк для работы с JSON-ом в .NET json.codeplex.com/, там хорошая дока с примерами.
-5
Интересное сравнение. Но помимо XML существуют и другие форматы. Например json или Protocol Buffers. А в WP7 можно хранить объекты в изолированом хранилище. Смотрели в их сторону или сразу остановились на XML?
-3
Насколько я помню, перед тем как использовать данные из изолированного хранилища, их прежде туда необходимо как-то добавить (стянуть с интернета, например), разве не так?
А у меня приложение было полностью независимое от интернета, поэтому использовал 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
0
Изолированое хранилище можно использовать как угодно вне зависимости от интернета. Вопрос в скорости работы. XML у вас ведь где-то хранится. Вы его парсите каждый раз при запуске программы. Было бы интересно увидеть насколько изменится скорость загрузки данных, если они один раз выгрузятся в изолированое хранилище в виде объектов и будут переиспользоваться. Насколько это быстрее/медленнее загрузки из XML.
А хранить список элементов можно разными способами.
А хранить список элементов можно разными способами.
0
На самом деле, вопрос сильно зависит от того, что именно вы хотите получить. Работать напрямую с xml? А зачем? Может быть, надо работать с объектом, и его сериализовать/десериализовать? Или что-то третье?
0
Спасибо! Интересная статья! Интересное сравнение.
Ещё раз убедился в правильности использования linq to xml для работы с xml.
В примере не требуется сложной обработки содержимого xml. Если же работать с xml, как с БД (поиск/обработка данных), то linq покажет себя намного лучше!
Ещё раз убедился в правильности использования linq to xml для работы с xml.
В примере не требуется сложной обработки содержимого xml. Если же работать с xml, как с БД (поиск/обработка данных), то linq покажет себя намного лучше!
0
>Если же работать с xml, как с БД (поиск/обработка данных), то linq покажет себя намного лучше!
А чем был мотивирован выбор именно XML если нужно с ним работать как с БД? Не проще ли было использовать нормальную БД?
А чем был мотивирован выбор именно XML если нужно с ним работать как с БД? Не проще ли было использовать нормальную БД?
0
Спасибо за статью, буквально на прошлой неделе задался подобным вопросом когда работал с сервисами возвращающими только XML. Вы на него отлично ответили!
0
Статья была бы гораздо более полезной, если бы были приведены графики потребления памяти. Вот там разница будет куда большей.
+1
Необычное сравнение. Если начать при чтении с помощью XmlReader строить DOM, то результаты сравнения скорее всего будут совершенно другие. Поэтому, не совсем понимаю сей затеи… а LINQ2XML не только быстрее, но и удобнее :)
0
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%, не более). Приходится актуальные данные держать в памяти — иначе работать не комфортно.
0
Внезапно, StAX быстрее DOM! В целом выводы-то верные, наверное, но включили бы в статью объяснение различия в этих технологиях, ну и вариант с dom но без XPath.
0
Sign up to leave a comment.
Производительность: LINQ to XML vs XmlDocument vs XmlReader на Desktop и Windows Phone