Ответ: да, но ...
Существует несколько проблем, которые необходимо решить :
0,1. Если файл XML огромен, я подозреваю, что большое время обработки затрачивается не на оценку самого выражения XPath , а на синтаксический анализ файла XML.
0,2. Всегда старайтесь избегать использования //
сокращения , так как оно чаще всего вызывает очень медленную оценку. Если вы знаете структуру XML-документа и b:book
появляется только в определенных местах, его будет гораздо эффективнее использовать (например):
/*/b:book[contains(b:author,'Melville')]
чем
//b:book[contains(b:author,'Melville')]
0,3. Только в том случае, если вы не можете сделать .2. выше, тогда вы можете реализовать следующее :
Вызов в цикле SelectSingleNode()
для следующих выражений (индекс должен быть счетчиком цикла):
(//b:book[contains(b:author,'Melville')])[1]
(//b:book[contains(b:author,'Melville')])[2]
(//b:book[contains(b:author,'Melville')])[3]
(//b:book[contains(b:author,'Melville')])[4]
. , , , , , , , , , , , , .
Если предположить, что оптимизатор исправен и перестанет оценивать полное выражение, когда найдет искомый вхождение, оценка первых выражений будет намного быстрее, чем оценка полного выражения //b:book[contains(b:author,'Melville')]
.
Конечно, время для выбора последних узлов будет по-прежнему очень большим, поэтому вы можете использовать смешанную стратегию: выбрать первые N (скажем, 100) узлов один за другим, а затем оценить полное выражение //b:book[contains(b:author,'Melville')]
.