XML, несколько МБ, in-memory vs stream-based

6yrop

На сервере требуется обрабатывать XML файлы размером в несколько мегабайт.
Какой парсер использовать in-memory ocument или stream-based XmlReader?
Как понять получим ли мы OutOfMemoryException на проде или нет, если выберем in-memory?

Dasar

Если обработка одного документа сводится к потоковой обработке, то XmlReader.
Если обработка одного документа требует множества сложных запросов к xml, то ocument/XElement.

6yrop

Если обработка одного документа требует множества сложных запросов к xml, то ocument/XElement.

Для того, чтобы ответить на этот вопрос фактически надо представить детально алгоритм обработки XML документа. В начале проекта это сопряжено с большой вероятностью ошибки такой оценки. Можно что-то упустить, или просто какие-то детали еще не известны в начале проекта.
Сейчас навскидку кажется, что потокового достаточно, но фиг знает как проект будет развиваться.
Поэтому хочется идти от обратного, что мы теряем, выбрав ocument?

Dasar

Поэтому хочется идти от обратного, что мы теряем, выбрав ocument?

Много памяти, немного производительности.
Посмотри на своих документах с каким коэффициентом использует память ocument по отношению к xml-ю в виде текста. И пляши от этого числа.

6yrop

Посмотри на своих документах с каким коэффициентом использует память ocument по отношению к xml-ю в виде текста. И пляши от этого числа.

Есть пример xml файла 800Кб.
После ocument.Load() память увеличивается примерно на 1M.
После ocument.Descendants().Select(_ => _.Value).ToList() память увеличивается еще на 2-3M.
Итого: 3-4M.
Что дальше?

Dasar

.ToList()

на хрена? память жрет. Если цель потрогать все Node-ы, то ocument.Descendants().Count(_ => _.Value != null).

6yrop

на хрена? память жрет. Есть цель потрогать все Node-ы, то ocument.Descendants().Count(_ => _.Value != null).

Ок, в понедельник попробую.
А ocument в какой памяти свои объекты хранит в обычной куче или large object heap?
Вопрос в том, будет ли GC успевать убирать мусор, или будем получать OutOfMemoryExeption?

Dasar

А ocument в какой памяти свои объекты хранит в обычной куче или large object heap?

Afaik, в обычной.
Лучше проверить. Нагрузить все потоки созданием ocument-ов в бесконечном цикле и посмотреть как будет память меняться.

Fimida

Чем смотреть память?
Новичок

pilot

Для того, чтобы ответить на этот вопрос фактически надо представить детально алгоритм обработки XML документа. В начале проекта это сопряжено с большой вероятностью ошибки такой оценки. Можно что-то упустить, или просто какие-то детали еще не известны в начале проекта.
Сейчас навскидку кажется, что потокового достаточно, но фиг знает как проект будет развиваться.
Поэтому хочется идти от обратного, что мы теряем, выбрав ocument?

"premature optimization is the root of all evil" (с)
Делай как проще, а проще всего грузить сразу в память.

6yrop

"premature optimization is the root of all evil" (с)
Делай как проще, а проще всего грузить сразу в память.

Допустим, да, в память грузить проще, тогда остается определиться преждевременная или нет? Какой у тебя критерий преждевременности? Когда в проде начнут сыпаться OutOfMemoryExeption?
Насчет простоты. Пока нам надо пробежаться во xml файлу. Одноразовый проход по xml по простоте одинаков как с использованием ocument, так и с использованием XmlReader.

pilot

Ты воображаешь себя senior программистом или junior? Предлагаю Ребекке тебя проконсультировать.

6yrop

Ты воображаешь себя senior программистом или junior?

В данной теме это не важно.
Если это вопрос о моем опыте, то я работал как с ocument, так и с XmlReader.

Предлагаю Ребекке тебя проконсультировать.

Любой пользователь может высказаться.

Dimon89

Сейчас навскидку кажется, что потокового достаточно, но фиг знает как проект будет развиваться.

Вот когда встанет задача, тогда и переделаешь. Это же не миллионы строк кода, а всего один модуль. Если сомневаешься - скрой взаимодействие с XML за интерфейсом, чтобы гарантированно оставить все переделки в одном модуле.
Плюсуюсь к "premature optimization..."

Dasar

Если сомневаешься - скрой взаимодействие с XML за интерфейсом

В одном случае правила обработки принимают XmlReader, в другом - XElement. Такое за интерфейсом не скрыть.

schipuchka1

А расскажи почему ты вообще опасаешься OOM? Будет работать на компах с малым количеством оперативки?

6yrop

Недавно мы исправили проблему, когда получали OOM на объектах около 12M. Эти объекты в LOH.

zya369

А расскажи почему ты вообще опасаешься OOM? Будет работать на компах с малым количеством оперативки?

вот он, дух enterprise Java

schipuchka1

Вот этого и начинал бы. Значит не преждевременная.
А сколько объектов единовременно?

schipuchka1

Ну так. Лучше забирать больше и не течь + дефрагментировать. Как минимум обычно, т.к. память дешёвая.

6yrop

Значит не преждевременная.

Если получить уверенность, что ocument не использует LOH, то вроде как преждевременная.
С другой стороны есть расходы CPU на GC http://samsaffron.com/archive/2011/10/28/in-managed-code-we-...

pilot

А чо правда на жаве писать дольше чем ты тут рассуждаешь?

6yrop

А чо правда на жаве писать дольше чем ты тут рассуждаешь?

Смотря что писать.

6yrop

Нашел полезные ссылки:
http://msdn.microsoft.com/en-us/library/bb387008.aspx
http://msdn.microsoft.com/en-us/library/bb387035.aspx?f=255...