使用自己的xml解析器和system.xml命名空间之间的性能差异是多少

Question

我正在尝试为我的游戏编写一个xml解析器，因为在使用system.xml命名空间时，最终版本的大小会增加1+ mb。解析器类是一个单例，可以随时在游戏中访问。虽然我要处理的数据量并不多，但我仍然担心性能（因为它是游戏，我不能牺牲任何性能）。

有没有办法有效地处理解析。顺便说一句，我正在使用c＃，如果有一个名为<tag>的标签，我只是将字符串分解成片段，搜索<tag>和</tag>。这将以递归方式继续，直到整个字符串完全分解为止。结果将保存在我创建的锯齿状列表类中。

有什么办法，我可以改进我的方法，或者我应该使用System.XML名称空间。

另外需要注意：xml数据来自服务器，而不是来自本地文件。

Answer 1

一些注意事项（这应该是评论，但是太长了）：

1. 我无法重现你的问题。使用控制台应用程序，我添加了对System.Xml的引用，创建了XmlDocument，使用它并编译，并且没有看到任何有意义的大小增加。
2. System.Xml是.Net基类库的一部分。通常，您可以指望它在运行.Net的每台计算机上（例如，根据msdn，XmlDocument在XNA中可用，但在便携式类库中没有。）
3. 如果它是框架的一部分，请确保未在引用上设置Copy Local = True。默认值应为false，但如果为true，则会将900 KB DLL复制到目标文件夹。
4. 没有人能够回答哪个更快 - 答案是非常相对的 - 什么类型的XML（小？大？）？什么类型的机器？您的用户将使用这些XML执行哪些操作？只有您可以通过分析代码来回答这些问题。
5. 即使你发现XmlDocument很慢或太大，.Net也有无数XML parsers - 也许其中一个对你有好处。 （甚至.Net有XDocument，但它也需要System.Xml.dll，所以没有收获）
6. 通常，多个字符串操作很慢。如果你描述的方法一直在搜索和分割sting，那么听起来很慢 - 我怀疑你需要不止一次扫描字符串来解析XML。

Answer 2

我不会这样做。我的意思是。已经存在可靠的工具。不要重新发明轮子。

Answer 3

您当然可以编写更快的XML解析器，尤其是如果您的功能较少的话。如果它做得少而且不那么健壮，那么它应该更快。不过，我会提醒你注意这一点，因为一旦你的应用程序的一部分声称“支持XML”但只是部分地这样做，那么如果你的XML生产者决定开始添加你的解析器不支持的东西，它将来可能会破坏但任何普通的XML解析器都会。

我之前从另一个方向跑过这个。我们需要增加发送到嵌入式设备的数据，并决定添加一些我们稍后可以阅读的属性。当我们发现设备无法读取我们的数据时，我们感到很惊讶。事实证明，解析器完全是本地的，很难被认为是真正的XML解析器，因为它需要标记在不同的行上，并在添加属性时断开。

如果您使用自己的解析器（可能不会像.NET .NET解析器一样强大），那么您应该谨慎地传达您所做和不支持的内容。