Почему querySelector ('#id') не сопоставляется с документом.getElementById ('id')?

в последнее время я занимаюсь производительностью селекторов, и меня беспокоит, что браузеры, которые в настоящее время реализуют API селекторов, не используют document.getElementById когда простой #id передается.

штраф за производительность огромный, поэтому авторы библиотеки продолжают реализовывать свой собственный путь вокруг этого.

какие идеи?

10
browser css-selectors javascript selectors-api

4 ответов

сделав свой комментарий выше, я решил следовать до конца:

Из Узла.cpp в исходном коде Chromium

if (strictParsing && inDocument() && querySelectorList.hasOneSelector() && querySelectorList.first()->m_match == CSSSelector::Id) {
    Element* element = document()->getElementById(querySelectorList.first()->m_value);
    if (element && (isDocumentNode() || element->isDescendantOf(this)) && selectorChecker.checkSelector(querySelectorList.first(), element))
        return element;
    return 0;
}

Так тут карта на getElementById, просто разбор строки, ищущей селекторы, является дорогостоящей операцией.

12

Tbh. штраф за исполнение незначителен... Я действительно сомневаюсь, что вы собираетесь делать 100.000 id поисков в секунду, если вы это сделаете, то производительность QSA на самом деле последнее, что вы должны смотреть.

Что касается того, почему добавление дополнительного if / else может сделать поиск id более эффективным, но тогда другие селекторы css будут немного (все еще незначительными) медленнее. Зачем оптимизировать QSA для работы с id-поиском, когда есть специальный метод, чтобы сделать это намного быстрее в любом случае.

в любом случае, браузеры нацелены на скорость и оставляют такие вещи, как это, делает графики общей производительности намного лучше. В этой контрольной гонке это действительно примерно каждая миллисекунда, но для разработчиков... пожалуйста, будьте реалистичны, другие критерии более важны,производительность QSA больше не должна быть фактором.

Что касается удобства разработчика, он работает, это все еще так быстро, что вы не заметите его в реальных приложениях (я бросаю вам вызов чтобы показать мне, где это визуально заметно, все еще будучи вменяемой программой ;o).

3

может быть, потому что, если бы они это сделали, им пришлось бы добавить проверку, чтобы увидеть, будет ли это простой запрос id (без модификаторов), который замедлит каждый другой запрос? Это может быть не огромный хит производительности, чтобы сделать тест, но его трудно говорить для других разработчиков.

Я думаю,если вы беспокоитесь об этом, вы можете добавить функцию, такую как getObByID, которая проверяет документ, getElementById, использует его, если он существует, иначе использует селектор. Может быть, разработчики не чувствуют необходимости добавить этот тип абстракции, когда вы можете легко сделать это самостоятельно, и это будет до разработчиков, чтобы помнить, чтобы использовать его, и увеличить кривую обучения.

0

я сравнивал getElementById() и querySelector() и обнаружил, что кто-то уже сделал сравнение производительности и расчеты.

Это, конечно, выглядит так, как будто querySelector() wins каждый раз... и немалую сумму.

0