2017-10-02 4 views
-2

Cela pourrait être incommensurable, mais je vais quand même demander. Par curiosité.Est-ce qu'un `if` simple est plus rapide que` else if 'quand il casse une boucle?

Dans ce code:

for (var i = 0; i < 10; i++) { 
 
    if (i > 5) { 
 
    break; 
 
    } 
 
    
 
    console.log("Do some stuff:", i); 
 
}

je lance une boucle pour 6 itérations et cassez le 7.

Dans ce code:

for (var i = 0; i < 10; i++) { 
 
    if (i > 5) { 
 
    break; 
 
    } else { 
 
    console.log("Do some stuff:", i); 
 
    } 
 
}

Je fais à peu près le même, sauf le code qui fonctionne avant que la boucle est rompue est à l'intérieur d'un else au if qu'il casse.

Évidemment, le résultat est le même. Cependant, ces deux morceaux de code sont-ils traités différemment à un niveau inférieur? L'un d'eux est-il même légèrement plus rapide? Est-ce que cela fait une différence autre que l'apparence?

+0

Cela dépend vraiment de la VM que vous ciblez, il pourrait très bien utiliser les mêmes instructions pour les deux exemples ici pour une VM mais pas pour une autre. Il n'y a pas non plus de réponse concrète pour le scénario en général, un petit changement de contexte pourrait amener le compilateur à changer complètement le code. – MinusFour

Répondre

0

La syntaxe n'a pas de caractéristiques de performance. On peut suggérer que les algorithmes dans la spécification qui régissent le comportement de la syntaxe impliquent des caractéristiques de performance, mais ce n'est pas nécessairement vrai non plus.

Surtout dans le cas des compilateurs optimiseurs modernes, votre code est entièrement réécrite de toute façon, même dans certains cas où il ressemble une chose devrait être fait plus ou moins vite que l'autre, il ne peut pas tourner réellement à être.

Comme pour toutes les questions de performance, en particulier dans le cas des micro-optimisations, l'analyse comparative est la manière de déterminer, et même dans ce cas, les résultats doivent être pris avec un grain de sel. refléter les résultats que vous avez observés dans l'indice de référence, en partie en raison de la réécriture de code que j'ai mentionnée ci-dessus, ou peut-être aussi en raison de failles dans le test de référence lui-même.