XML DataContractSerializer doubles the output size of an XML serializer - is it really faster and more scalable?

Question

I am updating the service and now I am using the DataContractSerializer to output the response. The previous version simply used custom serialization w / XmlSerializer. Since this version often used attributes, and DCS never does this, I see that the new response size is 1.5x the size of the previous version when compressed with gzip. (Or almost 3 times the size when uncompressed).

My question now is whether DCS will really be a faster and more scalable solution than XmlSerializer.

Answer 1

Who said it will be faster and more scalable? I do not remember that this was one of the key benefits of DCS. Someone once said that DCS can serialize faster, but transfer times can often obscure serialization. Serialization is 10% faster and creating a larger payload can actually cause a 20% increase in overall latency.

If you don't like the size, you can try to compress the original XML using shorter names in the DataMember attribute . This approach also works with the XmlSerializer, though using the XmlElement attribute. With DCS, you will always be at a disadvantage for the XmlSerializer in terms of the smallest possible size due to the economical size of the elements compared to attributes.

Answer 2

So, the answer seems to be that the DataContractSerializer is slower than the XMLSerializer if you think about it in terms of reducing the size of the XML payload. (Which for me is a critical component of measuring performance in the real world). There are some good things about DCS that are good, but if speed matters, skip it.

I would be interested to know if anyone disagrees with this.