Сериализация XML медленная

Question

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

После нескольких лет обслуживания это приложение постепенно начало показывать свой возраст. Руководитель группы сказал, что основная причина этого заключается в «медлительности» сериализации xml. Я испытываю желание вызвать BS по этому поводу, но многие из xml-файлов, с которыми мы имеем дело, имеют размер более 2 МБ, и, имея в виду основы того, что происходит за кулисами с объектами, отмеченными [Serializable], 2 МБ очень Подумайте над тем, чтобы в теории медлительности была доля правды.

По вашему опыту, действительно ли сериализация настолько медленная / плохая, что выбирает модель XML -> XPath вместо модели XML -> POCO?

Кстати, это проект .NET 2.0, и наши клиенты могут перейти на .NET 3.5 в конце следующего года.

Answer 1

В общем, нет, я не думаю, что замедление связано с сериализацией XML; 2 МБ не так велико, и это не должно вызывать какого-либо серьезного замедления.

Что меня больше всего беспокоит, так это то, что руководитель группы говорит вам, с чем связано замедление, не предоставляя вам никакой конкретной информации о профилировании, ПОКАЗЫВАЯ, что это именно так. Мнения об оптимизации часто ошибочны; Профилирование существует с целью точного определения того, где происходит замедление в приложении. Я бы порекомендовал инструменты и профилирование приложения, а также найти, где замедление; Держу пари, что это не в Сериализации XML.

Answer 2

Сериализация Xml не использует атрибут Serializable. Сериализатор xml фактически генерирует сборку, которая отображает xml на объект, он не использует отражение. Это одна из причин, по которой сериализация Xml работает только с публичными пользователями.

Одна вещь, которую вы можете попробовать, это измерить, используя DataContractSerializer, который является частью WCF. Было бы интересно увидеть разницу.

Я никогда не сталкивался с ограничением производительности лично, но у меня также нет больших объектов, таких как ваше описание.

Следует обратить внимание на конструктор, который вы используете для создания XmlSerializer, некоторые из них не кэшируют сгенерированную сборку и приведут к потере производительности и утечке памяти, поскольку каждый вызов будет генерировать все больше сборок. Если это так, у вас есть два варианта:

1) Кэшируйте созданный вами экземпляр сериализатора. Я считаю, что это потокобезопасно, но вы захотите перепроверить MSDN.
2) Используйте другой конструктор для создания XmlSerializer.

Answer 3

Поскольку это еще не было упомянуто здесь, я подумал, что должен указать, что в VS есть опция для генерации сборок сериализации XML во время сборки.

http://msdn.microsoft.com/en-us/library/kb4wyys2(v=VS.100).aspx

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

Это сокращает время, необходимое для сериализации типа, потому что, как говорит JoshBerke выше, XmlSerialiser генерирует новую сборку всякий раз, когда ему требуется сериализация или десериализация, что может занять время для сложных типов. Таким образом, предварительная генерация сборочных серий может привести к значительному повышению производительности.

Answer 4

Запустите профилировщик и посмотрите, на что тратится большая часть процессорного времени. Оказывается ли это сериализацией XML или где-то еще, вы будете знать, где сосредоточить свои усилия. Также, к сведению, я видел, что сериализация XML была удивительно медленной в прошлом в мире Java при работе с Spring RPC. Так что, вполне возможно, ваш начальник прав, но вместо того, чтобы угадывать, вам следует проверить.