Suponiendo que no haya optimizaciones locos (estoy mirando a ti Chrome).¿Cuál es la complejidad de tiempo de HTML DOM búsquedas
Estoy hablando de crudo, desagradable, ¿No-quiebra-no-fix-it, es decir v6 javascript, costo.
Cuanto menor sea el ser límite:
document.getElementById()
Versus:
document.getElementsByTagName('div') lookup.
getElementById puede suponer con seguridad que O(1) en un navegador moderno como una tabla hash es la estructura de datos perfecta para el id => mapeo de elementos.
Sin ninguna optimización, cualquier consulta simple, ya sea un selector css, una búsqueda de id, una búsqueda de nombre de clase o etiqueta, no es peor que O(n) ya que una iteración sobre todos los elementos siempre es suficiente.
Sin embargo, en un buen navegador esperaría que tuviera un mapeo tagname => elements, por lo que getElementsByTagName sería O(1) también.
y sin ninguna optimización getElementsByTagName tendrá que ser O (n) incluso en el mejor de los casos ya que el último elemento podría ser el que está buscando –
Entonces, ¿eso significa que los navegadores asignan múltiples vistas para cada etiqueta en escritura para maximizar la velocidad de lectura ? ¿No sería eso un poco más intensivo de memoria? –
El uso de memoria de esas asignaciones sería irrelevante. Sería mucho menos que, por ejemplo, una sola imagen (como una imagen de fondo en un sitio web) almacenada en la memoria caché. – ThiefMaster
Si usted está optimizando para IE 6, me animo a reconsiderar la parte '¿No-broke'. – robrich
@robrich No estoy optimizando nada. Sólo curioso. Pensé que el ie6 marcaría el sarcasmo detrás de 'aint-broke'. Tal vez debería "citarlo al aire" para mayor claridad. –