Est-ce plus rapide accédant à un tableau JavaScript directement?

Je fais généralement cela (déplacez le test de longueur en dehors de la boucle pour la boucle) xxx pré>

ou pour la compacité ... p>

var nl = document.getElementsByTagName("p");
for(var i=0,nll=nl.length;i<nll;i++){
    p = nl[i];
}

Non, cela ne sera pas plus rapide. En réalité, il est presque totalement absurde depuis pour chaque étape de la boucle de la boucle, vous appelez le "getelementsbytagname" qui est une fonction de consommation de temps.

La boucle idéale serait la suivante: P>

nl = document.getElementsByTagName("P");

for (var i = nl.length-1; i >= 0; i--)
{
    p = nl[i];
}

L'auteur de l'article a écrit:

Dans la plupart des cas, cela est plus rapide que de mettre en cache la nodéliste. Dans le deuxième exemple, le navigateur n'a pas besoin de créer l'objet Liste des nœuds. Il n'a besoin que de trouver l'élément à l'index i à ce moment exact.

comme toujours cela dépend. Cela dépend peut-être du nombre d'éléments de la nodelle. Pour moi, cette approche n'est pas sûre si le nombre d'éléments peut changer, cela pourrait causer et indexer de la liaison.

de l'article que vous liez sur:

Dans le deuxième exemple, le navigateur n'a pas besoin de créer l'objet Liste des nœuds. Il n'a besoin que de trouver l'élément à l'index i à ce moment exact.

Ceci est un non-sens. Dans le premier exemple, la liste des nœuds est créée et une référence à celle-ci est détenue dans une variable. Si quelque chose se passe, qui provoque la modification de la liste des nœuds - disons que vous supprimez un paragraphe - alors le navigateur doit alors faire du travail pour mettre à jour la liste des nœuds. Toutefois, si votre code ne provoque pas la liste de la liste, ce n'est pas un problème.

Dans le deuxième exemple, loin de ne pas avoir besoin de créer la liste des nœuds, le navigateur doit créer la liste des nœuds à chaque fois via la boucle , puis trouver l'élément à l'index i. Le fait qu'une référence à la liste des nœuds ne soit jamais affectée à une variable ne signifie pas que la liste ne doit pas être créée, car l'auteur semble penser. La création d'objets est chère (peu importe ce que l'auteur dit à propos des navigateurs "optimisés pour cela"), il va donc s'agir d'une grande performance touchée pour de nombreuses applications.

L'optimisation dépend toujours de l'utilisation réelle du monde réel que vos rencontres de candidature. Des articles tels que cela ne devraient pas être considérés comme disant «toujours fonctionner de cette façon» mais comme étant des collections de techniques, dont l'une pourrait, dans un ensemble de circonstances spécifique, être de valeur. Le deuxième exemple est, à mon avis, moins facile à suivre, et cela le met à lui seul dans le domaine des techniques de Tricksy qui ne devraient être utilisées que s'il existe un avantage éprouvé dans un cas particulier.

(Franchement, je ne fais pas confiance aux conseils offerts par un programmeur qui utilise un nom de variable comme "NL". S'il est trop paresseux pour utiliser des noms significatifs lors de la rédaction d'un tutoriel, je suis content de ne pas avoir à maintenir son code de production.)