DataContractSerializer XML удваивает размер вывода сериализатора XML - действительно ли это быстрее и масштабируемее? - PullRequest
4 голосов
/ 20 августа 2009

Я обновляю службу отдыха и теперь использую DataContractSerializer для вывода ответа. Предыдущая версия просто использовала пользовательскую сериализацию с XmlSerializer. Поскольку эта версия часто использует атрибуты, а DCS никогда не использует, я вижу, что новый размер ответа в 1,5 раза больше, чем у предыдущей версии при сжатии с помощью gzip. (Или почти в 3 раза больше, когда не сжато).

Мой вопрос заключается в том, действительно ли DCS будет более быстрым и масштабируемым решением, чем XmlSerializer.

Ответы [ 2 ]

4 голосов
/ 20 августа 2009

Кто сказал, что это будет быстрее и масштабируемее? Я не помню, чтобы это было одним из ключевых преимуществ DCS. Кто-то однажды сказал, что DCS может сериализоваться быстрее, но время передачи часто будет меньше времени сериализации. Сериализация на 10% быстрее и генерирование большей полезной нагрузки может фактически привести к увеличению общей задержки на 20%.

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

1 голос
/ 21 августа 2009

Хорошо, похоже, ответ таков: DataContractSerializer медленнее, чем XMLSerializer, если вы думаете об этом с точки зрения уменьшения размера полезной нагрузки XML. (Что для меня является критически важным компонентом измерения производительности в реальном мире). Есть некоторые вещи в DCS, которые хороши, но если скорость важна, пропустите ее.

Мне действительно было бы интересно узнать, не согласен ли кто-нибудь с этим.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...