Question

我在VB 6.0应用程序中使用MSXML v3.0。应用程序计算每个循环使用的所有节点的属性总和，如下所示

Set subNodes = docXML.selectNodes("//Transaction")
For Each subNode In subNodes
total = total + Val(subNode.selectSingleNode("Amount").nodeTypedValue)
Next

这个循环花费了太多时间，有时需要15-20分钟才能获得6万个节点。我正在寻找XPath / DOM解决方案来消除这个循环，可能是

docXML.selectNodes("//Transaction").Sum("Amount")

或

docXML.selectNodes("Sum(//Transaction/Amount)")

欢迎任何建议更快地获得这笔款项。

Answer 1

//打开XML。 docNav = new XPathDocument（@“c：\ books.xml”）;

//创建一个导航器以使用XPath进行查询。 nav = docNav.CreateNavigator（）;

//找到总和 //此表达式使用标准XPath语法。 strExpression =“sum（/ bookstore / book / price）”;

//使用Evaluate方法返回已计算的表达式。 Console.WriteLine（“书籍的价格总和是{0}”，nav.Evaluate（strExpression））;

来源：http://support.microsoft.com/kb/308333

Answer 2

在具有60000+节点的XML文档上使用XPath //伪运算符的任何解决方案都会非常慢，因为//x会导致完全遍历树从文档的根开始。

如果使用更精确的XPath表达式，那么解决方案可以显着加速，但不包括//伪运算符。

如果您了解XML文档的结构，请始终使用特定的位置步骤链 - 永远不要//。

如果您提供一个小示例，显示文档的特定结构，那么许多人将能够提供比使用//的任何解决方案更快的解决方案。

例如，如果已知可以使用此XPath表达式选择所有Transaction元素：

/x/y/Transaction

然后评估

sum(/x/y/Transaction/Amount)

可能明显快于Sum(//Transaction/Amount)

<强>更新：

OP在评论中透露，XML文件的结构非常简单。

因此，我尝试使用以下60000 Transaction个节点的XML文档：

/*/*/Amount

使用.NET XslCompiledTransform（是的，我使用XSLT作为XPath引擎的主机）这需要220ms（毫秒），这意味着0.22秒，以产生总和。

使用MSXML3需要334秒。

使用MSXML6需要76秒 - 仍然很慢。

结论：这是MSXML3中的一个错误 - 尝试升级到另一个XPath引擎，例如.NET提供的引擎。

使用XPath的DOM元素的总和

2 个答案: