XPath 显式索引过滤器性能答案

【问题标题】：XPath explicit index filter performanceXPath 显式索引过滤器性能
【发布时间】：2015-06-12 05:14:00
【问题描述】：

我正在创建一个 xsl stylehseet 并想出了这个（在我看来不合逻辑的行为）：

这个 XPath：

/root/element[1][@attr1 != '1' 或 @attr2 != 'test']

比这个 XPath 慢：

/root/element[count(preceding-sibling::element) + 1 = 1) and (@attr1 != '1' or @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 (/root/element/child/anotherChild)。

【问题讨论】：

这当然令人惊讶。但我不会使用“不合逻辑”这个词。 root下的元素children数量是不是很大？在这种情况下，第一个表达式可能正在查看所有元素，而第二个表达式在第一次匹配后停止（该表达式是否在只需要第一次匹配的上下文中使用？）
我添加了一些示例 xml，也许您可以解释为什么带有显式过滤器的 XPath 比带有 count(preceding-sibling::element) 的 XPath 慢得多。
抱歉，我不了解微软 XPath 处理器的内部结构，所以无法解释它的优化策略。

标签： c# xml performance xslt xpath

【解决方案1】：

我得出的解决方案是我必须接受这一点。微软说https://support.microsoft.com/en-us/kb/815124：

MSXML 的所有版本（3.0 版及更高版本）都使用显式索引过滤器更快。性能的提升取决于元素在父元素的子列表中的位置。而不是使用以下内容：

/child_element

使用以下内容：

/child_element[1]

就我而言，第一个示例比微软的建议要快得多。

【讨论】：