DOMNodeList的问题是，它实际上是一个非常简单的列表，因此像length和item(i)这样的操作有O(n)的成本，可以在代码中看到，例如这里的长度：

XMLSize_t DOMNodeListImpl::getLength() const{
    XMLSize_t count = 0;
    if (fNode) {
        DOMNode *node = fNode->fFirstChild;
        while(node != 0){
            ++count;
            node = castToChildImpl(node)->nextSibling;
        }
    }

    return count;
}

因此，如果不希望DOM树在迭代时发生更改，则不应使用DOMNodeList，因为访问O(n)中的项从而使迭代成为O(n^2)操作-等待发生的灾难（即足够大的XML文件）。
使用DOMNode::getFistChild()和DOMNode::getNextSibling()是一个足够好的迭代解决方案：

DOMNode *child = docNode->getFirstChild();
while (child != nullptr) {
    // do something with the node
    ...
    child = child->getNextSibling();
}

这在O(n)中如预期的那样发生。
也可以使用DOMNodeIterator，但是为了创建它，需要正确的DOMDocument，当需要迭代时，它并不总是在手边。

是的，在我发布后不久，我添加了代码来存储和管理每个节点的子计数，这产生了很大的不同。重复访问相同的节点，每次都重新计算子节点计数。这是一个相当昂贵的操作，因为Xerces基本上为该节点重新构建DOM结构以保证其活性。我们有自己的对象，它封装了一个Xerces DOMNode沿着我们需要的额外信息，我们使用DOMNode：：setUserData将我们的对象与相关的DOMnode相关联，现在这似乎是最后剩下的瓶颈。