¿Qué es mejor para su uso como una perspectiva de rendimiento:jQuery selector sola vs .find()
$(".div1 h2, .div1 h3")
o
selector de$(".div1").find("h2, h3")
¿Qué es mejor para su uso como una perspectiva de rendimiento:jQuery selector sola vs .find()
$(".div1 h2, .div1 h3")
o
selector de$(".div1").find("h2, h3")
La respuesta a tu pregunta es: sí.
No se preocupe por la diferencia de rendimiento, a menos que su código sea lento. Si es así, use un generador de perfiles para determinar los cuellos de botella.
Desde el punto de vista de análisis:
$(".div1 h2, div1 h3")
debería ser más rápido como jQuery canalizarla a través de querySelectorAll
(si existe) y nativa código se ejecutará más rápido que el código no nativo. También ahorrará en una llamada de función adicional.
$(".div1").find("h2, h3")
es mejor si usted planea en el encadenamiento de algunas otras funciones en .div1
:
$(".div1").find("h2, h3").addClass('foo').end().show();
"lento" para mí significa más de aproximadamente '0.3s' para la mayoría de las funciones de JS. No hay forma de que deje que el navegador se cuelgue durante 1s, mucho menos 10. Si pasa mi "umbral lento", refactorizaría el código y analizaría el rendimiento. – zzzzBov
Sí, tiene razón, en este caso la diferencia de rendimiento no es un gran problema. Pero ten cuidado con esa oración. Estoy un poco traumatizado por ver varios problemas de rendimiento y la gente piensa "si funciona, no me importa más" ... – BrunoLM
lo que quise decir con mi afirmación es que no debes preocuparte por el rendimiento a menos que sea un problema. Nunca dije que el código descuidado estaba bien, pero no me importa un conjunto O (n^3) de bucles si son comprensibles y no están causando problemas de rendimiento. Si lo hicieran, ciertamente trabajaría para reducirlos lo más cerca posible de O (n). – zzzzBov
http://jsperf.com/selector-vs-find-again
es más rápido
(NOTA : compuso html aleatorio solo para que no fueran solo esos elementos en la página)
Wow, eres rápido;). – Thai
Esta es la respuesta real; en lugar de simplemente "no importa". Importa porque OP preguntó. – Akash
¿tiene algún elemento sobre lo que lo hace más rápido? Instintivamente habría pensado que el hallazgo sería más rápido. Entonces, tengo curiosidad por lo que hace que sea más lento. – Ar3s
Use jsPerf.
En realidad, .find() PUEDE ser más rápido.
Los selectores parecen ser más rápidos de encontrar al intentar seleccionar múltiples elementos; sin embargo, si usa $ .find, o incluso almacena en caché el descendiente, puede ver que es mucho más rápido: http://jsperf.com/selector-vs-find-again/11
También me gustaría diferir sobre el rendimiento no es importante. En este mundo de teléfonos inteligentes, la duración de la batería es el rey.
Esto es interesante, pero en este caso no buscará 'h2' y' h3' que solo son descendientes de 'div1'. – Dan
@Dan El "caché de búsqueda" en realidad usa div1, pero simplemente lo almacena en la caché como: 'var cache = $ (". Div1 ");' Dicho esto, Firefox no parece pensar que uno sea más rápido. En ese caso, estás en lo correcto, el "buscador de velocidad" encontrará todos los 'h2'' h3', pero es simple darles clases directamente como: '$ .find (". Classh2, .classh3 ")' al objetivo específicos. – Drath
Acabo de encontrar esta respuesta y quiero agregar algunos números aquí, puede ser que alguien los encuentre útiles y curiosos. En mi caso busqué el selector jQuery
más rápido para un elemento único. No me gusta agregar ID sin razón, así que busqué la forma de seleccionar elementos sin ID.
En mi pequeña investigación usé awesome selector profiler para jQuery. Y aquí está el código disparé directamente desde la consola de Chrome después añadí código de la biblioteca de perfiles:
$.profile.start()
// Lets
for (i = 0; i < 10000; i++) {
// ID with class vs. ID with find(class)
$("#main-menu .top-bar");
$("#main-menu").find(".top-bar");
// Class only vs element with class
$(".top-bar");
$("nav.top-bar");
// Class only vs class-in-class
$(".sticky");
$(".contain-to-grid.sticky");
}
$.profile.done()
Aquí hay resultados:
jQuery profiling started...
Selector Count Total Avg+/-stddev
#main-menu .top-bar 10000 183ms 0.01ms+/-0.13
nav.top-bar 10000 182ms 0.01ms+/-0.13
.contain-to-grid.sti... 10000 178ms 0.01ms+/-0.13
.top-bar 10000 116ms 0.01ms+/-0.10
.sticky 10000 115ms 0.01ms+/-0.10
#main-menu 10000 107ms 0.01ms+/-0.10
undefined
más lentos selectores están en la parte superior de esta tabla. Los más rápidos están en la parte inferior. Sorprendentemente para mí justo después del selector por ID, es decir, $('#main-menu')
, he encontrado selector de clase única, p. .top-bar
y .sticky
. ¡Aclamaciones!
Para averiguarlo, puede crear un perfil de su código: http://jsperf.com/ –
Consulte [esta respuesta] (http://stackoverflow.com/a/12177876/323407) para obtener información relacionada con el rendimiento, pero diferencia importante Personalmente, no me preocuparía las diferencias de microsegundos a menos que el código se ejecute en un bucle o que esté escribiendo una biblioteca que será utilizada por terceros. – Tgr
el problema suele ser el mismo, 10⁶ x 1microsec hace 1 seg :) –