xpath - XPath: / // より速い?

Question

私がそれを正しく/理解した場合、その右のノードはその左のノードの直接の子でなければならないことを意味します。たとえば/ul/li、ドキュメントルートである ul アイテムの直接の子である li アイテムを返します。//ul//liドキュメント内のどこかにある ul アイテムの子孫である li アイテムを返します。

今:結果セットが同じであっても、/ul/liより高速ですか?//ul//li

Answer 1

一般的に言えば、もちろんです！

/ul/li最大深さ 2 で、最大で (number_of_ul * number_of_li ノード) を訪問します。ドキュメント内のすべてのノードを//ul//li訪問する可能性があります。

ただし、ある種の索引付けを備えたドキュメント システムを使用している場合や、最終的に同じ数のノードがアクセスされるドキュメントを使用している//可能性があります。よりもさらに高速です/ul/li。いずれにせよ、すべてのノードを訪問する非常に愚かな XPath 実装を潜在的に持つこともできると思います。

どちらが速いかを尋ねるのではなく、特定のシナリオをプロファイリングする必要があります。「場合による」が答えです。

Answer 2

XPath にはおそらく少なくとも 50 の実装があり、それらのパフォーマンスは数桁も劇的に異なります。したがって、特定の実装を参照せずに XPath のパフォーマンスについて質問しても意味がありません。

一般的には、できる限り具体的なパスを使用することをお勧めします。/a/b/c/d は //d よりも優れています。ただし、このアドバイスは常に正しいとは限りません。一部の製品は、インデックスを作成する手間を省いたため、 //d の実行速度が速くなります。これは、XML データベースに対して実行している場合に特に当てはまります。また、パフォーマンスがすべてではありません。FpML のような複雑なボキャブラリーを扱っている場合、要素への特定のパスは、平均 20 文字の名前を持つ 10 のステップになることがあります。つまり、これは 200 文字の XPath であり、間違えると見つけるのが非常に困難になる可能性があります。プログラマーのパフォーマンスは、マシンのパフォーマンスよりも重要です。