XPath的明確指標過濾器的性能

我創建一個XSL stylehseet以及與此想出了（在我看來不合邏輯的行爲）：XPath的明確指標過濾器的性能

這個XPath：

/根/元素[1] [@ attR1位！= '1' 或@ attR2位= '測試']

是WAY比這個慢的XPath：

/根/元素[計數（preceding- （@ attr1！='1'或@ attr2！='test'）]

我有50個樣本xml，第一個XPath需要55秒。
第二個XPath需要~4秒！

我使用XslCompiledTransform（C＃.NET 4.5）。

有人可以解釋爲什麼第一個XPath比第二個慢得多？我一直認爲最好使用顯式索引過濾器。

更新：一些示例XML：

<?xml version="1.0" encoding="iso-8859-1"?> 
<root> 
<element attr2="test" attr1="1"> 
    <child>17</child> 
    <child>17</child> 
    <child>16</child> 
    ... 
    <child>3</child> 
    <child>2</child> 
    <child>1</child> 
</element> 
<element attr2="test2" attr1="2"> 
    <child/> 
    <child/> 
    <child/> 
    <child/> 
    <child/> 
    <child/> 
    <child/> 
    ... 
    <child/> 
</element> 
.... 
<element attr2="test21" attr1="21" />

只有像20-25的元件，其中n兒童的但深度最大爲4（/根/元件/子/ anotherChild）。

來源

2015-06-12 Tony

這當然令人驚訝。但我不會用「不合邏輯」這個詞。根源下的元素兒童數量非常大？在這種情況下，第一個表達式可能會查看所有元素，而第二個表達式可能會在第一次匹配後停止（是否需要僅在第一個匹配時使用的表達式？） –

我添加了一些示例xml，也許您可以解釋爲什麼具有顯式過濾器的XPath比具有計數的XPath（preceding-sibling :: element）慢得多。 – Tony

對不起，我不知道微軟的XPath處理器的內部，所以我不能解釋任何關於它的優化策略。 –

我來到解決方案，我只需要接受這一點。微軟稱https://support.microsoft.com/en-us/kb/815124：

MSXML 3.0版的所有版本及更高版本，與明確的指標過濾速度更快。性能的提高取決於元素在父級的子級列表中的位置。代替使用以下的：

/CHILD_ELEMENT

使用下面的：

/CHILD_ELEMENT [1]

以我的情況下，第一個例子是WAY比從微軟recommandation更快。

來源

2015-07-14 05:38:52 Tony

XPath的明確指標過濾器的性能

回答

相關問題