使用自己的xml解析器和system.xml命名空间之间的性能差异有多大
本文关键字：xml 性能 之间 system 自己的 命名空间 | 更新日期: 2024-10-23 10:59:27
我正试图为我的游戏编写一个xml解析器，因为在使用system.xml命名空间时，最终构建的大小增加了1+mb。解析器类是一个单例，可以在游戏中随时访问。虽然我要处理的数据量不多，但我仍然担心性能（因为这是一场比赛，我不能牺牲任何性能）。
有没有任何方法可以有效地处理解析。顺便说一句，我使用的是c#，如果有一个名为<tag>的标签，我只是将字符串分解为几个部分，搜索<tag>和</tag>。这将递归地继续，直到整个字符串被完全分解。结果将保存在我创建的锯齿状列表类中。
有什么方法可以改进我的方法吗？或者我应该使用System.XML名称空间。
另一个注意事项是：xml数据来自服务器，而不是来自本地文件。
一些注释（这应该是一个注释，但太长了）：
- 我无法重现你的问题。使用控制台应用程序，我添加了对
System.Xml的引用，创建了XmlDocument，使用了它并进行了编译，但没有看到任何有意义的大小增加 System.Xml是.Net基类库的一部分。通常，您可以指望它在每台运行.Net的计算机上（例如，根据msdn，XmlDocument在XNA中可用，但在可移植类库中不可用）- 如果它是框架的一部分，请确保没有在引用上设置Copy Local=True。默认值应为false，但如果为true，则会将一个900 KB的DLL复制到目标文件夹中
- 没有人能回答哪个更快——答案与什么类型的XML（小？大？）非常相关？在什么类型的机器上？您的用户将对这些XML执行哪些操作？只有您可以通过分析代码来回答这些问题
- 即使您发现XmlDocument速度慢或太大，.Net也有无数的XML解析器——也许其中一个对您有好处。（即使.Net有
XDocument，但它也需要System.Xml.dll，因此没有增益） - 通常，多个字符串操作是缓慢的。如果您描述的方法是不断地搜索和分割字符串，那么听起来很慢——我怀疑您是否需要多次扫描字符串来解析XML
我不会那样做。我是说。已经有了可靠的工具。不要重新发明轮子。
当然可以编写一个更快的XML解析器，尤其是在您的解析器功能较少的情况下。如果它做得更少，也不那么健壮，那么它应该更快。不过，我要提醒您不要这样做，因为一旦您的应用程序的某个部分声称"支持XML"，但只是部分支持，那么如果您的XML生成器决定开始添加解析器不支持但任何普通XML解析器都支持的东西，那么它在未来可能会崩溃。
我以前从另一个方向穿过这个。我们需要增加发送到嵌入式设备的数据，并决定添加一些稍后可以读取的属性。当我们发现该设备无法读取我们的数据时，我们感到很惊讶。事实证明，该解析器完全是自己开发的，很难被视为真正的XML解析器，因为它要求标记位于单独的行上，并且在添加属性时会中断。
如果您推出自己的解析器（它可能不如普通的.NET解析器那么健壮），请注意，您可以准确地传达您所做的和不支持的内容。