-->

决定何时使用XmlDocument的VS的XmlReader(Deciding on when to

2019-07-20 10:27发布

我优化的自定义对象 - > XML序列化工具,这一切都完成,工作,这不是问题。

它的工作将文件加载到一个XmlDocument对象,然后通过所有的子节点递归去。

我想,也许使用XmlReader ,而不必XmlDocument加载/解析整个事情会更快,所以我实现那个版本。

该算法是完全一样的,我用一个包装类来处理一个抽象功能XmlNode与一个XmlReader 。 例如, GetChildren方法得到的回报无论是孩子XmlNode或子树XmlReader

所以我写了一个测试驱动程序,测试两个版本,并使用复杂数据集(周围1350元一个900KB的XML文件)。

然而,使用JetBrains公司dotTRACE,我看到XmlReader版本实际上比慢XmlDocument版本! 它似乎有参与一些显著处理XmlReader读取调用时,我遍历子节点。

所以我说所有的问这个:

有什么优势/劣势XmlDocumentXmlReader ,并在您应该使用什么情况下要么?

我的猜测是,有将在哪个文件大小阈值XmlReader成为性能更加经济,以及更少的内存密集型。 然而,这个门槛似乎是1MB以上。

我打电话ReadSubTree每处理子节点时间:

public override IEnumerable<IXmlSourceProvider> GetChildren ()
{
    XmlReader xr = myXmlSource.ReadSubtree ();
    // skip past the current element
    xr.Read ();

    while (xr.Read ())
    {
        if (xr.NodeType != XmlNodeType.Element) continue;
        yield return new XmlReaderXmlSourceProvider (xr);
    }
}

该测试适用于大量的对象在一个级别(即宽和浅) -但我不知道如何很好XmlReader票价时,XML是深宽&? 即我处理的XML很像一个数据对象模型,1个父对象的许多子对象,等等: 1..M..M..M

我也不知道事先我解析的XML的结构,所以我不能优化它。

Answer 1:

我一般看它不是从最快的角度 ,而是从存储利用率的角度。 所有实现的已经足够快的我用他们的使用场景(典型企业集成)。

然而,当我跌倒了,有时壮观,没有考虑到我的工作的XML的一般大小。 如果你想想看前面,你可以节省自己有些悲伤。

XML倾向于在被加载到存储器,至少带有DOM读取器等,以臃肿XmlDocumentXPathDocument 。 像10:1? 确切的量是很难量化的,但如果它是1MB的磁盘这将是10MB内存,或更多,例如。

使用加载整个文档到其全部存储器任何读者的方法( XmlDocument / XPathDocument )可以由大对象堆碎片苦,这可能最终导致OutOfMemoryException S(即使有可用的存储器),导致不可用的服务/处理。

由于在尺寸大于85K更大的物体最终在大对象堆,并且你已经有了一个10:1的大小爆炸与DOM的读者,你可以看到它并不需要太多的前正在从分配的XML文档大对象堆。

XmlDocument是非常容易使用。 它的唯一缺点是,它加载整个XML文档到内存中的过程。 它的诱惑简单易用。

XmlReader是一个基于流阅读器,以便将让你的程序内存使用率一般较平坦,但使用起来更困难。

XPathDocument往往是一个更快,只读版本的XmlDocument的,而是从记忆“膨胀”仍然受到影响。



Answer 2:

XmlDocument的是整个XML文档的内存中表示。 因此,如果您的文档比较大,那么它会占用更多的内存比,如果你一直在使用的XmlReader读它。

这是假设,当你使用的XmlReader你读取和处理元素一个接一个,然后将其丢弃。 如果您使用的XmlReader和构建存储另一个中介结构,那么你有同样的问题,而你战胜它的目的。

谷歌为“ SAX与DOM ”,以了解更多关于处理XML的两种模式之间的区别。



Answer 3:

另一个考虑是,XMLReader的可能是用于处理低于完全形成的XML更稳健。 我最近创建了使用的XML流的客户端,但流没有特殊字符中所含的一些元素的URI的正确转义。 为XMLDocument和XPathDocument中拒绝所有加载XML,而使用的XMLReader我能提取我从流所需的信息。



Answer 4:

有一个在其中的XmlDocument变慢,并最终无法使用尺寸阈值。 但门槛的实际值将取决于您的应用程序和XML内容,所以没有硬性规定。

如果您的XML文件可以包含大型列表(说元素数以万计的),你绝对应该使用的XmlReader。



Answer 5:

编码不同的是,因为两个不同的测量混合。 UTF-32需要每字符的4个字节,并且固有地比单字节数据慢。

如果你看一下大(100K)元素测试,你看到的时间大约为70ms的每一种情况下increasesw不管使用的加载方法的。

这是(几乎)恒定差具体由每字符的开销引起的,



文章来源: Deciding on when to use XmlDocument vs XmlReader