#java #html-parsing #jsoup
#java #html-синтаксический анализ #jsoup
Вопрос:
Я понимаю, что после загрузки документа в Jsoup, используя Jsoup.parse()
, синтаксический анализ снова не требуется, поскольку аккуратно иерархическое дерево готово для использования программистом.
Но я не уверен, является ли выбор верхнего уровня () более дорогостоящим, чем выбор внутреннего уровня ().
Например, если у нас есть <p>
скрытый внутри многих вложенных <div>
s, и этот <p>
родительский элемент уже доступен в программе, будет ли какая-либо разница в производительности между:
document.select("p.pclass")
и
pImediateParent.select("p.pclass")
?
Как это работает в Jsoup?
ОБНОВЛЕНИЕ: основываясь на приведенном ниже ответе, я понимаю, что оба document.select()
и pImediateParent.select()
используют один и тот же точный статический метод, только с другим корнем в качестве второго параметра:
public Elements select(String query) {
return Selector.select(query, this);
}
Что приводит к:
/**
* Find elements matching selector.
*
* @param query CSS selector
* @param root root element to descend into
* @return matching elements, empty if not
*/
public static Elements select(String query, Element root) {
return new Selector(query, root).select();
}
Я не удивлен, но теперь вопрос в том, как это query
работает? Выполняется ли итерация для поиска запрошенного элемента? Является ли это запросом с произвольным доступом (как в хэш-таблице)?
Ответ №1:
Да, это будет быстрее, если вы используете промежуточный родительский элемент. Если вы проверите исходный код Jsoup, вы увидите, что Element#select()
на самом деле делегирует Selector#select()
метод с Element
самим собой в качестве 2-го аргумента. Теперь javadoc этого метода говорит:
выберите
public static Elements select(String query, Element root)
Найдите элементы, соответствующие селектору.
Параметры:
- запрос — селектор CSS
- root — корневой элемент для перехода в
ВОЗВРАТ:
совпадающие элементы, пустые, если нет
Обратите внимание на описание root
параметра. Так что да, это определенно имеет значение. Не шокирует, но есть некоторая разница.
Комментарии:
1. Спасибо! Я обновил свой вопрос выше, чтобы добавить ссылки на исходный код. Теперь вопрос заключается в рентабельности инвестиций при «кэшировании» промежуточного родителя. Если он будет использоваться в качестве корня запроса много раз в цикле (по сравнению с использованием document в качестве корня), это действительно может повысить производительность, верно?
2. Да, но это скорее microboost, чем megaboost. Или вы, должно быть, просматриваете необычайно большой HTML-документ> 10 МБ или что-то в этом роде. Измерение (профилирование) — это знание.