使用XPath的DOM元素總和

我在VB 6.0應用程序中使用MSXML v3.0。該應用程序計算如下圖所示使用XPath的DOM元素總和

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

這個循環花費過多時間，有時也需要15-20分鐘60000個節點使用每個循環中所有節點的屬性的總和。我要尋找的XPath/DOM，要徹底解決這個循環中，可能

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

或

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

任何建議是值得歡迎的更快得到這筆錢。

來源

2011-06-06 bjan

//打開XML。 docNav =新的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

來源

2011-06-06 14:08:34 signetro

當我使用VB 6.0時，您指定的來源清楚地提到「...通過使用Visual C＃」，而我使用VB 6.0 – bjan 2011-06-06 15:09:04

開始在該使用XPath //僞操作XML文檔上有60000+的節點將是相當緩慢，因爲//x引起的任何解決方案的樹的遍歷完整文檔的根。

如果使用更精確的XPath表達式，則不會包含//僞操作符，可以顯着提高解決方案的速度。

如果您知道XML文檔的結構，請始終使用特定的位置步驟鏈 - 從不使用//。

如果您提供一個小例子，顯示文檔的特定結構，那麼許多人將能夠提供比使用//的任何解決方案更快的解決方案。

/x/y/Transaction

然後

sum(/x/y/Transaction/Amount)

評價很可能是顯著快於Sum(//Transaction/Amount)

：

例如，如果已知所有Transaction元件可以使用該XPath表達式選擇

更新：

OP在評論中透露，XML文件的結構非常簡單。

因此，我試着用60000個Transaction節點的XML文檔如下：

/*/*/Amount

在.NET XslCompiledTransform（是的，我用XSLT作爲主機的XPath引擎）這場耗時220ms內（毫秒），這意味着0.22秒，以產生總和。

使用MSXML3需要334秒。

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

結論：這是MSXML3中的一個錯誤 - 嘗試升級到另一個XPath引擎，例如.NET提供的引擎。

來源

2011-06-07 04:40:33

@bjan：就像...什麼？ – 2011-06-07 04:52:50

的XML文檔的結構是一樣 \t \t \t -20011.61 \t \t \t \t \t – bjan 2011-06-07 04:54:33

我什特定的鏈條，但循環仍需要時間。實際上，查找節點列表的代碼並不慢，但循環遍歷它們以找到總和較慢。 – bjan 2011-06-07 09:33:21

使用XPath的DOM元素總和

回答

相關問題