1

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

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

有什么办法，我可以改进我的方法，还是应该只使用 System.XML 命名空间。

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

4

3 回答 3

5

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

  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 解析器- 也许其中一个对您有好处。（即使 .Net 有XDocument，但它也需要System.Xml.dll，所以没有收获）
  6. 通常，多个字符串操作很慢。如果您描述的方法是不断搜索和拆分字符串，那听起来很慢 - 我怀疑您需要多次扫描字符串才能解析 XML。
于 2012-08-06T05:59:38.983 回答
2

我不会那样做。我是说。已经有可靠的工具。不要重新发明轮子。

于 2012-08-06T05:24:20.147 回答
2

您当然可以编写一个更快的 XML 解析器，尤其是在您的功能较少的情况下。如果它做得更少并且不够健壮，那么它应该更快。不过，我会提醒您不要这样做，因为一旦您的应用程序的一部分声称“支持 XML”但只是部分这样做，那么如果您的 XML 生产者决定开始添加您的解析器不支持的东西，它可能会在未来中断但任何普通的 XML 解析器都会。

我以前遇到过这个，从另一个方向。我们需要扩充我们发送到嵌入式设备的数据，并决定添加一些我们以后可以读取的属性。当我们发现该设备无法读取我们的数据时，我们感到很惊讶。事实证明，解析器完全是国产的，几乎不能被认为是真正的 XML 解析器，因为它要求标签位于不同的行上，并且在添加属性时会中断。

如果您使用自己的解析器（可能不如现有的 .NET 解析器那么健壮），请务必小心，您可以准确地传达您支持和不支持的内容。

于 2012-08-06T06:15:52.570 回答