DataContractSerializer XML 是 XML 序列化器输出大小的两倍 - 这真的更快、更具可扩展性吗？
我正在升级一个宁静的服务，现在使用 DataContractSerializer 来输出响应。以前的版本仅使用带有 XmlSerializer 的自定义序列化。因为该版本使用了很多属性，而 DCS 从来没有这样做，所以我发现使用 gzip 压缩时，新的响应大小是以前版本大小的 1.5 倍。 （或未压缩时大小的近 3 倍）。
我的问题是 DCS 是否真的会成为比 XmlSerializer 更快、更具可扩展性的解决方案。
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
谁说它会更快、更具可扩展性？我不记得这是 DCS 的主要优势之一。有人曾经说过，DCS 可以更快地串行化，但传输时间往往会使串行化时间相形见绌。串行速度提高 10% 并生成更大的有效负载，实际上可能会导致总体延迟增加 20%。
如果您不喜欢这个大小，可以尝试在 DataMember 属性。不过，此方法也可以使用 XmlElement 属性与 XmlSerializer 配合使用。使用 DCS，由于元素与属性的大小经济性，在最小可能大小方面您将始终处于 XmlSerializer 的劣势。
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.
好吧，如果您从缩小 XML 负载大小的角度来考虑，那么答案似乎是 DataContractSerializer 比 XMLSerializer 慢。 （对我来说，这是衡量现实世界性能的关键组成部分）。 DCS 有一些优点，但如果速度很重要，请跳过它。
我真的很想看看是否有人不同意这一点。
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.