我继承了一个项目，其中应用程序的数据模型是 XML 文档。我之前的开发人员已经根据这个 xml 的模式创建了一个对象模型，然后针对该对象模型进行编码。
经过几年的维护，这款应用逐渐开始显老。团队负责人表示，这背后的关键原因是由于 xml 序列化的“缓慢”。我很想在这方面给 BS 打电话，但是我们处理的许多 xml 文件的大小都超过 2MB，并且请记住标记为[Serializable] 的对象在幕后发生的基本情况，2MB 是很多反思一下，这样慢速理论可能会有一些道理。
根据您的经验，序列化真的那么“慢”/糟糕到选择 XML -> XPath 模型而不是 XML -> POCO 模型吗？
顺便说一句，这是一个 .NET 2.0 项目，我们的客户可能会在明年晚些时候升级到 .NET 3.5。
【问题讨论】：
标签： design-patterns serialization xml-serialization
一般来说，不，我不认为减速是由于 XML 序列化； 2MB 并没有那么大，应该不会导致任何严重的减速。
我更关心的是，团队负责人会告诉你减速的原因，但没有给你任何具体的分析信息，告诉你情况确实如此。关于优化的观点经常是错误的；分析存在的目的是准确地找到应用程序中发生任何减速的位置。我建议对应用程序进行检测和分析，并找出减速的地方；我敢打赌它不在 XML 序列化中。
【讨论】：
Xml 序列化不使用 Serializable 属性。 xml 序列化程序实际上会生成一个将 xml 映射到对象的程序集，它不使用反射。这是 Xml 序列化仅适用于公众的原因之一。
您可以尝试的一件事是使用 WCF 的一部分 DataContractSerializer 进行测量。看到差异会很有趣。
我个人从未遇到过性能限制，但我也没有像您描述的那样大的对象。
需要注意的一点是您用于创建XmlSerializer 的构造函数，其中一些不会缓存生成的程序集，并且会导致性能损失和内存泄漏，因为每次调用都会生成越来越多的组件。如果是这种情况，您有两种选择：
1) 缓存您创建的序列化程序实例。我相信它是线程安全的，但您需要仔细检查 MSDN。
2) 使用不同的构造函数来创建 XmlSerializer。
【讨论】：
DataContractSerializer 不是 WCF 的一部分； WCF 大量利用它，但它位于 WCF 之外（在它自己的命名空间和自己的程序集中）。
DataContractSerializer 的cmets 也是正确的，它不是WCF 的一部分。
运行分析器并查看大部分 CPU 时间都花在了哪里。无论结果是 XML 序列化还是其他地方，您都会知道将精力集中在哪里。此外，作为记录，过去在 Java 世界中，当使用 Spring RPC 时，我发现 XML 序列化速度非常慢。所以，你的老板当然有可能是对的，但你应该检查而不是猜测。
【讨论】：
由于这里还没有提到，我想我应该指出 VS 中有一个选项可以在构建时生成 XML 序列化程序集。
http://msdn.microsoft.com/en-us/library/kb4wyys2(v=VS.100).aspx
如果您想要更细粒度的控制，也可以手动使用 sgen.exe 进行生成。
这减少了序列化类型所需的时间，因为正如 JoshBerke 上面所说，XmlSerialiser 会在需要序列化或反序列化时生成一个新程序集，这对于复杂类型来说可能需要一些时间。因此，预生成序列化程序集可以显着提高性能。
【讨论】：