В последнее время я участвую в производительности селекторов, и это подталкивает меня к тому, что браузеры, которые в настоящее время реализуют API Selectors, не используют document.getElementById, когда передается простой #id.
Снижение производительности огромное, поэтому авторы библиотеки продолжают реализовывать свой собственный подход.
Любые идеи?
После того, как я сделал свой комментарий выше, я решил следовать:
Из Node.cpp в источнике хрома
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, это просто, что синтаксический анализ строки, ищущей селекторов, является дорогостоящей операцией.
ТВН. штраф за производительность незначителен... Я действительно сомневаюсь, что вы будете делать 100 000 поисковых запросов в секунду, если вы это сделаете, то производительность QSA на самом деле является последней вещью, на которую вы должны обратить внимание.
Что касается того, почему добавление дополнительного if/else могло бы сделать поиск идентификатора более результативным, но тогда другие css-селектора будут меньше (все еще незначительны) медленнее. Зачем оптимизировать QSA для работы с поиском идентификаторов, когда есть специальный метод, который делает это намного быстрее.
В любом случае, браузеры стремятся к быстроте и оставляют вещи, как это делает общие графики производительности намного лучше. В этой тестовой гонке это ДЕЙСТВИТЕЛЬНО о каждой миллисекунде, но для разработчиков... пожалуйста, будьте реалистичны, другие тесты важнее, производительность QSA больше не должна быть фактором.
Что касается удобства разработчиков, он работает, он все еще так быстр, что вы не заметите его в реальных приложениях (я призываю вас показать мне, где он ВИЗУАЛЬНО заметен, хотя он все еще является разумной программой, o).
Может быть, потому что если бы они это сделали, им пришлось бы добавить чек, чтобы увидеть, является ли его простой запрос id (без модификаторов), который замедлит каждый другой запрос? Это может не быть большим успехом, чтобы выполнить тест, но его трудно говорить для других разработчиков.
Я думаю, что если вы беспокоитесь об этом, вы можете добавить func, например getObByID, который проверяет документ, getElementById, использует его, если он существует, а другой использует селектор. Возможно, разработчики не чувствуют необходимости добавлять этот тип абстракции, когда вы можете легко сделать это самостоятельно, и разработчикам не придется запоминать его использование и увеличивать кривую обучения.
Я сравнивал getElementById() и querySelector() и обнаружил, что кто-то уже выполнил сравнения производительности и вычисления.
Кажется, что querySelector() выигрывает каждый раз... и значительная сумма.