Me gusta el rendimiento de los selectores últimamente, y me molesta que los navegadores que actualmente implementan la API de Selectores no utilicen document.getElementById cuando se pasa un simple #id.¿Por qué querySelector ('# id') asigna a document.getElementById ('id')?
La penalización de rendimiento es huge, por lo que los autores de las bibliotecas continúan implementando su propio camino.
¿Alguna idea?
Después de hacer mi comentario anterior, decidí seguir adelante:
De Node.cpp en la fuente de cromo
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;
}
Por lo que hace mapa en getElemenById, es sólo que el análisis La cadena que busca selectores es una operación costosa.
¡Gracias, David! No sabía dónde mirar en la fuente de Chromium. – Ronny
Tal vez porque si lo hicieran, tendrían que agregar un cheque para ver si es una simple consulta de identificación (sin modificadores) que ralentizaría cada otra consulta? Puede que no sea un gran golpe de rendimiento para hacer la prueba, pero es difícil hablar en nombre de otros desarrolladores.
Creo que si le preocupa puede agregar un func como getObByID que busca documentos, getElementById, lo usa si existe, de lo contrario utiliza el selector. Quizás los desarrolladores no sientan la necesidad de agregar este tipo de abstracción cuando pueden hacerlo fácilmente por sí mismos, y les correspondería a los desarrolladores recordar usarla y aumentar la curva de aprendizaje.
Tbh. la penalización de rendimiento es insignificante ... Realmente dudo que vayas a hacer 100.000 búsquedas por id. Si lo haces, entonces el rendimiento de QSA es lo último que debes mirar.
En cuanto a por qué, agregar un if/else extra puede hacer que las búsquedas id sean más efectivas, pero luego otros selectores css serán una fracción (aún insignificante) más lenta. ¿Por qué optimizar QSA para hacer frente a las consultas de identificación cuando hay un método especializado para hacer exactamente eso mucho más rápido de todos modos.
En cualquier caso, los navegadores apuntan a la velocidad y omitir cosas como esta hace que los gráficos de rendimiento general se vean mucho mejor. En esta carrera de referencia, REALMENTE es sobre cada milisegundo, pero para los desarrolladores ... sean realistas, otros puntos de referencia son más importantes, el rendimiento de QSA no debería ser un factor más.
En cuanto a la conveniencia del desarrollador, funciona, sigue siendo tan rápido que no lo notarás en las aplicaciones reales (te reto a que me muestres dónde es VISIBLE VISUALMENTE sin dejar de ser un programa sensato; o).
Estaba comparando getElementById() y querySelector() y encontré que alguien ya ha hecho performance comparisons and calculations.
Sin duda, parece como si querySelector() gana cada vez ... y por una cantidad considerable .
Creo que puede tenerlo al revés. – bento
No he visto la fuente de esos navegadores, pero ¿está seguro de que no se asignan directamente? Habrá una penalización de rendimiento para analizar la cadena y calcular si solo es una identificación directa. – Quentin
Chicos si hace clic a través de esa prueba jsperf vinculada en la pregunta, debe quedar claro que si el navegador * intenta * derivar un selector '#id' a la resolución 'getElementById()', está haciendo un * terrible * trabajo de eso Probablemente no lo intente. – Pointy
Bien, aquí hay algunas pruebas: [WebKit * does * map 'querySelector' on' document.getElementById'] (http://codesearch.google.com/codesearch/p#OAMlx_jo-ck/src/third_party/WebKit/WebCore/ dom/Node.cpp & l = 1580 & exact_package = chromium) – Gumbo