i

i
Parfois il suffit d’un rien pour accélérer des scripts, et comme ça ne coûte rien et que ça peut rendre service, il faut s’en servir.
Aujourd‘hui, l’astuce est toute bête, mais je ne la voit pas tant que ça non plus, d’où mon partage.

break

Quand on fait une boucle (for, while…) sur un tableau ou une liste, par exemple pour trouver un élément particulier du tableau, on peut gagner beaucoup de temps en sortant du tableau une fois qu’on a trouvé le résultat.

Ainsi, au lieu de ça :


// soit $array un tableau de 1 000 éléments
for (var i=0, len=array.length; i<len ; i++) {
    if (array[i] === recherche) {
        console.log('élément trouvé : ' + i);
    }
}


On peut faire ça :

// soit $array un tableau de 1 000 éléments
for (var i=0, len=array.length; i<len ; i++) {
    if (array[i] === recherche) {
        console.log('élément trouvé : ' + i);
        break;
    }
}


Où est l’optimisation ?
Il est avec le break : étant donnée qu’ici on recherche un élément du tableau en particulier, une fois qu’on l’a trouvé, il est inutile de perdre du temps de chercher dans les éléments qui suivent. Par conséquent, on va utiliser break pour sortir de la boucle for dès qu’on a rempli la condition.

Un élément recherché dans un tableau se trouve en moyenne à la moitié du tableau (parfois au début, parfois à la fin, mais en moyenne, au milieu). Du coup, en moyenne, on gagne 50 % de temps de calcul.

Une autre solution plus adaptée dans le cas des conditions, mais moins flexible je trouve, pourrait être de faire avec while :


// soit $array un tableau de 1 000 éléments
var flag = false, i=0;
while (array[i] && !flag) {
    if (array[i] === recherche) {
        console.log('élément trouvé : ' + i);
        flag = true;
    }
    else {
        i++
    }
}


Perso je préfère utiliser for plutôt que while, mais ce dernier fonctionne aussi. En JS, il existe aussi .forEach, .each, for of, for in, tous pour leur propres application, mais on peut parfois utiliser break aussi (même si ça dénaturerait un peu le forEach, qui ne serait alors pas pertinent).

Notez que le gain de temps/énergie/temps processeur devient vite non-négligeable lorsque l’on commence à imbriquer plusieurs boucles for les unes dans les autres. Imbriquer 2 boucles de 1 000, ça fait 1 000 000 de tests à effectuer. Si les tableaux ne sont (virtuellement) plus que de 500, alors on réduit le temps de calcul de 75 % (plus que 250 000 calculs).

Bref, dès que vous le pouvez, sortez de la boucle et gagnez du temps.

À retenir : le break permet de sortir de la boucle. Son comportement est un peu différent du continue que voici.

continue

continue permet de sortir de l’itération courante dans une boucle, c’est pratique si l’on souhaite sortir de l’itération sans ajouter un if/else supplémentaire.

C’est utile, si je souhaite effectuer plusieurs calculs sur des éléments du tableau, mais que je dois exclure certains éléments.

Imaginons que l’on ait un tableau (de 1 000 éléments) d’objets "personne" et que seuls certains d’entre-eux ont renseigné leur âge. Pour ceux-là, et uniquement ceux-là, on souhaite vérifier si c’est leur anniversaire. Pour les autres, on ne fait rien.

Plutôt que de faire ça :


for(var i=0, len=array.length; i<len ; i++) {
    if (array[i].birthday !== undefined) {
        if (array[i].birthday === today) {
            console.log('Bon anniversaire !);
        }
    }
}


On peut faire ça :


for(var i=0, len=array.length; i<len ; i++) {
    if (array[i].birthday === undefined) {
        continue;
    }
    if (array[i].birthday === today) {
        console.log('Bon anniversaire !);
    }
}


Ici, si l’anniversaire n’est pas défini, on sort de l’itération en cours et l’on passe à la suivant : inutile d’effectuer les autres tests.

Ok, ici, c’est le gain est nul, mais dans certains cas il ne l’est pas.
Un exemple concret où je l’utilise c’est dans mon lecteur RSS : une fois que les éléments sont marqués comme lu, je ne souhaite plus les voir affichés, mais comme ils sont toujours sur la liste des éléments, il faut les ignorer.
Plutôt que d’utiliser un if/else ou un switch, j’utilise ça :

if (this.eventsList[i].action == "deleteEvent") continue;


Ça tient en une seule ligne, c’est discret et ça ne gêne pas la lecture du code.
D’autant plus que si l’élément n’est pas à supprimer, il peut avoir plusieurs autres .action
D’un point de vue « lecture du code », je préfère utiliser le if/else pour quand je dois effectuer une action dans les deux cas. Si je n’ai qu’un seul cas à traiter, je ne prends que if.
Si j’ai tous les cas à traiter (>2) je prends un switch, et si j’ai n-1 cas à traiter, je mets un continue au début, plutôt qu’un if suivi d’un gros else
Chacun ses façons de faire, mais j’apprécie celle-ci parce qu’elle réduit les niveaux d’indentation et le nombre de blocs indentés, qui rendent parfois le code difficile à suivre.


Conclusion

On peut décrire break et continue comme l’équivalent des return dans une fonction (si on ignore le fait que return renvoie un résultat en plus de terminer la fontion). Return a pour effet de terminer la fonction et renvoyer un résultat.
Break et continue ne retournent pas de résultat, mais terminent le code en cours :

  • break termine l’exécution de la boucle entière : il permet de sortir du while ou du for ;
  • continue termine l’exécution de l’itération en cours : il sort du tour de boucle et passe à la suivante.


Comme j’avais expliqué dans mon article sur la prog récemment, il n’y a pas qu’une seule façon de faire, mais si le but est de faire un code rapide et moins gourmand en ressources, il n’y a pas 36 solutions : il faut réduire l’empreinte CPU, et ça, ça passe surtout par le nombre de calculs qu’il doit effectuer (et dans une moindre mesure, le type de calculs, mais ça ça sera pour une autre fois).

image d’en-tête de Jun OHWADA

Commentaires fermés

Les commentaires sont fermés pour cet article