J'ai beaucoup d'éléments générés et référencés (mouseover, clics, changements de position) beaucoup de fois.
J'ai l'identifiant de ces éléments à portée de main. Est-il sage de stocker le document.getelementbyid (id) appels dans une variable ou est-ce plus rapide / juste aussi rapide / plus lent d'appeler document.getelementByID () à chaque fois?
5 Réponses :
Il est certainement plus rapide de stocker les éléments dans une variable, mais pas par une grande marge. C'est quelque chose qui est différent du cas au cas et devrait être adapté à chacun individuellement.
Peut-être que le plus gros facteur est la lisibilité, je crois que l'accès aux éléments directement est plus lisible. P>
theMainButton.style.color = "red";
// vs.
document.getElementById("theMainButton").style.color = "red";
Je cherche des gains de performance ici. Le code est mis en place dans des fonctions et n'a pas besoin de lire :)
Tous les codes ont besoin de lire, à moins que cela ne soit parfaitement écrit la première fois, il n'a jamais besoin d'être modifié ou étendu, n'a jamais besoin de nouvelles fonctionnalités et n'a jamais besoin d'être comprise. :)
Serait-il toujours plus rapide si vous le stockez dans une matrice / carte rare? Je demande parce que GetElementyID est-ce que l'ID est déjà déjà mis en cache, donc je ne sais pas s'il y a des gains pour avoir un cache des éléments qui ont déjà une identification (la recherche la plus rapide) qui enregistre les articles que vous alliez chercher Temps, mais dans le processus de recherche des données, vous faites essentiellement la même chose que GetElementyID ...
@DMitry: Dépend probablement de quelques éléments: navigateur, combien de fois vous l'utilisez (est le jit chaud ou non), où est l'objet stocké. Je ne peux pas imaginer que cela soit pertinent pour la performance du tout. Je serais intéressé à voir une référence cependant.
Vous devez bien sûr réutiliser la référence si possible, mais vous devrez peut-être obtenir une nouvelle référence dans chaque corps de fonction.
Exemple: P>
// This will recreate all elements inside the 'parent' element:
document.getElementById('parent').innerHTML += 'test';
C'est un bon point et j'aimerais ajouter que vous ne savez jamais qui, ou quoi, va changer un nœud Dom de vous. Je suis toujours favorable à l'obtention explicitement de la référence pour réduire les bugs et améliorer la lisibilité. Si vous gérez de nombreux nœuds dans une situation de haute performance, vous voudrez peut-être les assigner à la mémoire.
Ce seront environ 500 articles, mais ils seront gérés correctement. J'utilise JQuery et la plupart du temps, l'objet sera $ (jqueryfied) afin que je puisse appeler des fonctions comme la position (). Est-ce que la même chose va pour stocker l'objet $ ('# id1' ') en mémoire?
Oh, maintenant ça a du sens. Je me demandais pourquoi la mise en cache éclate des appels de fonction. (Bien sûr, je créais de nouveaux éléments là-bas).
Si les éléments restent dans le DOM et ne sont pas remplacés, puis Il est logique de les stocker dans un tableau, de sorte que vous puissiez les référencer autant de fois que vous le souhaitez sans frais de performance. Si cela aide, vous pouvez créer une fonction simple pour vous faire pour vous: getElementByID renvoie un noeud d'élément, qui est essentiellement juste un objet JavaScript. Vous pouvez affecter cet objet à une variable, ce qui signifie que la variable pointera sur cet objet chaque fois que vous tapez cette variable à une étape ultérieure. Ainsi, id1 fait maintenant référence à l'élément DOM avec un identifiant de id1 . Si aucun élément n'a été trouvé avec ce ID , alors document.getelementbyID retourne null.
Il n'y a pas de bonne réponse à cette question. Tout dépend de ce que vous devez travailler. Si vous travaillez avec une page qui a une quantité massive d'éléments dans l'arbre DOM, il est préférable de mettre en cache les références et de les réutiliser pour accélérer le temps de recherche. Si vous travaillez sur une petite page, il est préférable de rechercher des éléments à la volée et de minimiser la consommation de mémoire du navigateur.
Cela dépend également des navigateurs que vous ciblez. Par exemple, les versions les plus récentes de Firefox prennent un certain temps à un élément d'une première première fois, mais ils mettent en cache la référence en interne, alors vous allez le chercher, cela va être presque instantané. C'est-à-dire, d'autre part, ne cache pas les valeurs de recherche, mais elle cherche que le temps est beaucoup plus rapide que Firefox lors du premier essai.
Beaucoup de cadres modernes mettront en cache les éléments que vous avez trouvés pour vous. Cependant, je préfère personnellement utiliser le document.getElementyid la plupart du temps. Ce que je fais, lorsque j'ai besoin de cacher des valeurs de recherche, c'est ce qui suit: Vous l'utilisez en appelant le tableau et le transmettez-le d'un identifiant de l'élément. Lorsque vous devez récupérer la valeur, vous appelez get_element ID que vous avez passé et lors de la première exécution, il recherchera l'élément et le mettre en correspondance, sur chaque appel consécutif, il suffira de renvoyer la valeur mise en cache.
J'ai écrit une petite routine JS pour faire de l'analyse comparative à ce sujet, avec trois tests: -
Le test se situait dans dix millions de boucles d'itération et il existe évidemment de nombreux facteurs qui pourraient affecter le résultat (les chiffres ne sont même pas exactement les mêmes sur les points successifs avec une variance d'environ 10%), mais ils Offrez une «indication raisonnable».
Test 1 - 11 millisecondes
Test 2 - 3983 millisecondes
Test 3 - 3594 millisecondes
Un milliseconde peut ne pas sembler longtemps à vous, mais à votre ordinateur, c'est presque l'éternité. }
Ni vous devriez utiliser JQuery!
J'utilise jQuery. Pour les gains de performance: même question: Devrais-je mettre en cache l'objet JQuery ($ (# id1 ')) ou devrais-je appeler $ (' # id1 ') à chaque fois que j'en ai besoin?