DataContractSerializer XML double the size of XML serializer output - Is this really faster and more scalable?

Question

I'm upgrading a restful service, and am now using the DataContractSerializer to output the response. The previous version just used custom serialization w/ XmlSerializer. Because that version used attributes a lot, and DCS never does, I'm seeing that the new response size is 1.5x the size of the previous version when compressed with gzip. (Or nearly 3x the size when uncompressed).

My question then is whether DCS is really going to be a faster, more scalable solution than XmlSerializer.

Stephainestephan

DCS is generally faster - it was optimized to be fast - but it's also somewhat limited (doesn't support attributes, for one). You need to weigh what's more important to you - speed on serialization / deserialization, or small payload - you typically can't have both..... pick one. – Interpreter

So I guess you'll have to do some measurements for yourself - what is more important in your given scenario: speed on (de)serialization, or size of XML payload - only you can really decide that in the end – Interpreter

Thanks for the input marc. Given that this is designed to be fast, (public api, mobile users, response time requirements), it's a pretty easy call. I'm a little disappointed that all of the guidance appears so misleading w/ regard to speed. Hopefully this very useful info gets out. – Stephainestephan

Answer 1

Who said it was going to be faster and more scalable? I don't remember that being one of the key advantages of DCS. Someone once said that DCS can serialize faster, but transmission time will often dwarf serialization time. Serializing 10% faster, and generating a larger payload, may actually cause a 20% increase in the overall latency.

If you don't like the size, you can try to shrink the original XML by 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 to XmlSerializer in terms of smallest possible size, due to the size economics of elements vs attributes.

Riffe

Most of the searching I've done recommends DCS over XmlSerializer. Your answer seems to suggest you agree with my concerns in principle. Anyone else? Anyone have anything along the lines of a real-world benchmark? – Stephainestephan

Where'd you get the research? Here on SO, there is a "DCS is cool, XmlSerializer is soooo yesterday" attitude, but I don't agree with it and never understood it. It shouldn't be hard to benchmark it. BUT, I would suggest that perf ought not to be your primary criterion for choosing one over the other. Look at maintainability, serviceability, reliability, etc. – Riffe

Thanks for the reply Cheeso. I agree with that perspective of speed being generally secondary, and I'm afraid I agree on not agreeing that DCS is a good technology. That said, I'm working on a public, highly trafficked api that has some scalability and response time requirements that I have to be able to hit, both for our own site, and partners. Being public, I have to be able to maintain backward compatibility too, which means I'll be stuck with this decision for awhile. – Stephainestephan

It's not that DCS is so cool - it's quick, it has other advantages (it can serialize even private fields, it has an explicit "opt-in" model and only serializes what you tell it to) which do make it superior to XmlSerializer in some ways. It has other drawbacks (no support for attribute is one). – Interpreter

@Interpreter - yes, as you point out there are different advantages to DCS and XmlSerializer. What I'm saying is, the balance of attitude HERE has been that XmlSerializer is yesterday's technology, and is best forgotten or dismissed. I don't agree. – Riffe

@Jeff D - sounds like an interesting challenge for you. I don't think the serialization is going to kill you either way - both can be reasonably fast. A while back MS published a study that showed WCF was faster than ASMX, but I don't recall the details, not sure if DCS was used in WCF, and cannot find the paper now. The study was distributed with source code, which might be a good starting point for you. StockTrader 1.0 (not 2.0, which is WCF only). – Riffe

Answer 2

Ok, so it sounds as if the answer is that the DataContractSerializer is slower than the XMLSerializer if you're thinking about it in terms of shrinking the size of the XML payload. (Which to me is a critical component of measuring real-world performance). There are some things about DCS that are nice, but if speed is important, skip it.

I'd really be interested to see if anyone disagrees with this.

Stephainestephan

I disagree that size of XML is a good measure of performance. Will the XML be compressed? Encrypted? Will it be transmitted as text? In which encoding? Or as binary? This is a false measure, except that it points out that the XML Serializer does not give you most of those options. – Labile

If you can download x bytes/sec, and solution a is 10 bytes and solution b is 20, then a will take twice as long to transmit as b unless the sizes are below that of the packet. I'm assuming that network speed is tremendously more bottle-necking than the CPU, so the 10-15% CPU time probably wouldn't alter the equation appreciably. In my qustion I specified the sizes of the responses in plain text, and gzip compressed. The encoding shouldn't matter, as it would alter the sizes linearly. That said, I'll be using the JSONSerializer as well. That flexibility is nice – Stephainestephan