性能：XDocument 与 XmlDocument
我在此处阅读了两者之间的比较。这主要是一个性能问题，与内存和速度有关。
我有几个大小超过 100 - 300 K 的 XML 文档。我注意到将此信息加载到 XDocument 而不是 XmlDocument 对象时存在一些延迟。
- 这两个对象之间是否存在严重的性能差异？
- 他们访问 XML 内容的方式是否不同？
- 当使用 XML 字符串时，哪个是首选，或者有什么区别？
这些对象的最终用途是对相关对象运行查询（XPath 或 LINQ，具体取决于）。
I have read a comparison between the two here. This is primarily a question of performance, relating to both memory and speed.
I've got several XML documents that are upwards of 100 - 300 K in size. I've noticed that there is some lag when loading this information into an XDocument rather than an XmlDocument object.
- Is there a serious performance difference between these two objects?
- Do they access the content of the XML differently?
- When working with a string of XML, which is preferred, or is there a difference?
The end use of these object is to run queries (XPath or LINQ, depending) on the object in question.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
XmlDocument 是文档对象模型的纯托管实现。与任何 COM 组件（例如 MSXML 库）没有互操作性。否则任何索赔都是完全虚假的。通过在 .NET Framework 中引入 LINQ，整个 XLinq API 集作为一种与 XML 交互的更友好的方式而出现。
如果您想最大限度地提高性能并且习惯使用 XPath，请尝试使用 XmlDocument 并使用 编译的 XPath 表达式。
XmlDocument is a purely managed implemenation of the Document Object Model. There is no interop with any COM components, such as the MSXML library. Any claim otherwise is completely bogus. The entire XLinq set of APIs came about as a friendlier way to interact with XML with introduction of LINQ in the .NET Framework.
If you're trying to maximize performance and are comfortable using XPath, try using the XmlDocument and using compiled XPath expressions.
XmlReader是 .NET 中最低级的 API，.NET 中的所有其他 XML API 在幕后使用。当然，这意味着它是最难处理的，也是最快的。它是一个流式 API，因此也最适合内存。在
XmlDocument和XDocument又名 Linq to XML 之间，以下是一些原始数字：https://learn.microsoft.com/en-us/archive/blogs/codejunkie/xmldocument-vs-xelement-performance它发现
XDocument类更快/更高效。程序员的生产力/效率也不应该被忽视。就我个人而言，我发现使用XDocument更容易。XmlReaderis the lowest API in .NET which all other XML APIs in .NET use under the scenes. Naturally that means it's the hardest to deal with, as well as fastest. It's a streaming API, so it is best fit for memory as well.Between
XmlDocumentandXDocumentaka Linq to XML, here are some raw numbers: https://learn.microsoft.com/en-us/archive/blogs/codejunkie/xmldocument-vs-xelement-performancewhich finds
XDocumentclass being faster/more efficient. Programmer productivity/efficiency shouldn't be ignored as well. Personally I find it easier to work withXDocument.如果其他人仍在寻找答案......
我自己设法做了一些基准测试。看来 XDocument 大大超过了 XmlDocument。当然，您可能会想将 XmlReader 纳入其中，但这是另一个话题了。
这是我的小基准测试结果： https://github.com/zulimazuli/dotnetXmlBenchmarks
If anyone else is still looking for the answer...
I have managed to do some benchmarking by myself. It seems that the XDocument exceeds the XmlDocument quite substantially. Of course, you could be tempted to involve the XmlReader in this, but this is a topic for another time.
Here's my tiny benchmark result: https://github.com/zulimazuli/dotnetXmlBenchmarks