Wcf DataContractSerializer XML是XML序列化程序输出大小的两倍-这真的更快、更具可伸缩性吗？

我正在升级restful服务，现在使用DataContractSerializer输出响应。以前的版本只使用了自定义序列化w/XmlSerializer。因为那个版本使用了很多属性，而DCS从来没有使用过，所以我发现当使用gzip压缩时，新的响应大小是以前版本的1.5倍。（或在未压缩时接近3倍大小）

---

那么，我的问题是DCS是否真的会成为比XmlSerializer更快、更具可扩展性的解决方案

谁说它会更快、更具可扩展性？我不记得这是DCS的主要优势之一。有人曾经说过，DCS可以更快地序列化，但传输时间往往会缩短序列化时间。串行化速度加快10%，并生成更大的负载，实际上可能会导致总延迟增加20%

---

如果您不喜欢XML的大小，可以尝试在XML中使用较短的名称来缩小原始XML。不过，这种方法也适用于XmlSerializer，使用XmlElement属性。在DCS中，由于元素和属性的大小经济性，在最小可能大小方面，您将始终处于XmlSerializer的劣势。

好的，因此如果您考虑缩小XML有效负载的大小，那么答案似乎是DataContractSerializer比XmlSerializer慢。（对我来说，这是衡量现实世界绩效的关键组成部分）。DCS有一些优点，但如果速度很重要，请跳过它

---

我真的很想看看是否有人不同意这一点。

我所做的大部分搜索都推荐DCS而不是XmlSerializer。你的回答似乎表明你原则上同意我的担忧。还有其他人吗？有人有符合现实世界基准的东西吗？你从哪里得到的研究？在这里，有一种“DCS很酷，XmlSerializer很酷”的态度，但我不同意，也从来没有理解过。对其进行基准测试应该不难。但是，我认为性能不应该是你选择其中一个的主要标准。查看可维护性、可维护性、可靠性等。感谢您的回复。我同意速度通常是次要的观点，恐怕我也同意不同意DCS是一种好技术。也就是说，我正在开发一个公共的、流量很大的api，它具有一定的可伸缩性和响应时间要求，我必须能够满足这些要求，无论是对于我们自己的站点还是对于合作伙伴。作为公共的，我也必须能够保持向后兼容性，这意味着我将在一段时间内坚持这个决定。这并不是说DCS很酷——它很快，它还有其他优势（它甚至可以序列化私有字段，它有一个显式的“opt-in”模型，并且只序列化您告诉它的内容）这确实使它在某些方面优于XmlSerializer。它还有其他缺点（不支持attribute就是其中之一）。@marc_s-是的，正如您指出的，DCS和XmlSerializer有不同的优点。我想说的是，这里的态度平衡是XmlSerializer是昨天的技术，最好是忘记或抛弃它。我不同意。DCS通常更快-它被优化为更快-但它也有一定的局限性（例如，不支持属性）。您需要权衡对您来说更重要的是什么—序列化/反序列化的速度，还是较小的负载—您通常不能同时拥有这两个方面。。。。。选择一个。所以我想你必须自己做一些测量——在给定的场景中更重要的是：序列化速度，或者XML负载的大小——只有你才能在结尾真正决定这一点——谢谢你的输入。考虑到这是为了快速（公共api、移动用户、响应时间要求），这是一个非常简单的调用。我有点失望，所有的指导在速度方面都显得如此误导。我不同意XML的大小是衡量性能的一个好指标。XML会被压缩吗？加密的？它会以文本形式传送吗？哪种编码方式？还是二进制？这是一个错误的度量，只是它指出XML序列化程序没有为您提供大多数选项。如果您可以以x字节/秒的速度下载，解决方案a为10字节，解决方案b为20字节，那么a的传输时间将是b的两倍，除非大小低于数据包的大小。我假设网络速度比CPU的瓶颈要大得多，所以10-15%的CPU时间可能不会明显改变这个等式。在我的问题中，我用纯文本和gzip压缩指定了响应的大小。编码应该无关紧要，因为它会线性地改变大小。也就是说，我也将使用JSONSerializer。这种灵活性很好