2010-06-14 6 views
3

Imaginez que j'avais une variable appelée X. Disons toutes les 5 secondes que je voulais faire X = vrai. (Il peut être vrai ou faux entre ces 5 secondes, mais il redevient vrai quand les 5 secondes sont écoulées).quoi de plus efficace? vérifier == ou simplement muter la variable?

Serait-il plus efficace de vérifier si la valeur est déjà vraie, sinon, la réaffecter à true? Ou juste avoir X = vrai?

en d'autres termes, lequel serait plus rapide?

if(x==false){ 
    x = true; 
} 

vs

x = true; 

D'une part, le premier programme ne sera pas muter la variable si elle ne doit pas. D'autre part, le second programme n'a pas besoin de vérifier ce que X est égal à; il plonge directement.

+1

Cela ne fera aucune différence notable (sauf si x a eu des effets secondaires, tels que l'envoi d'événements, la réaction des auditeurs, etc., auquel cas la réponse est "ça dépend"). Faites ce qui est logique dans votre logique de programme. –

Répondre

8
  • Cela n'a presque pas d'importance. Écrivez le code le plus facile à comprendre et à maintenir. Seulement l'optimiser si nécessaire.
  • La meilleure façon d'être sûr est de le tester. Profil votre code.
  • Ce qui est plus rapide peut dépendre du navigateur.
  • Ce qui est le plus rapide dépend si la variable est généralement vraie ou généralement fausse. Cela dit, dans la plupart des scénarios, je suppose que la définition d'une variable sans test sera plus rapide.
+0

D'accord. Je mettrais mon argent juste en le changeant à 100% plutôt que de tester 100% et en le changeant de 50%. –

+0

@Mike M. et le 50% est une hypothèse qui pourrait ne pas être vrai - vient d'ajouter cela. Et je peux voir cwap a également fait ce point aussi. –

+1

Si 'x' n'est pas simplement une variable simple, mais par exemple une "classe" ou un grand tableau, il vaudrait mieux vérifier, puis définir. –

4

dépend vraiment de vos données :)

Si x == false 90% du temps, puis une affectation à droite x serait plus rapide.

C'est l'un de ces endroits où vous ne voulez probablement pas à vous soucier de l'efficacité, et si vous avez vraiment, profil, il ..

+0

+1 pour avoir réfléchi à la fréquence de faux vs vrai. –

1

L'efficacité de votre tentent d'atteindre par c'est infime par rapport l'efficacité atteint par la qualité de votre conception globale.

1

Disclaimer/Avertissement:

Ceci est un micro-optimisation , et ne sera jamais une incidence sur l'efficacité de votre programme d'une manière qui est mesurable par les utilisateurs. Si vous désactivez toutes les optimisations du compilateur et exécutez un excellent profileur, vous pourrez peut-être quantifier les effets, mais aucun utilisateur ne s'en apercevra.

Ceci est particulièrement vrai pour votre situation, où le code en question n'est exécuté que toutes les quelques secondes. Le temps consacré au profilage sera probablement mieux utilisé pour améliorer d'autres parties de votre application. En outre, dans ces situations, la lisibilité doit toujours prévaloir sur les micro-optimisations sans goulot d'étranglement (bien que ma réponse ci-dessous ne tienne compte que de l'efficacité d'exécution, comme demandé). Par conséquent, mon code recommandé pour vous d'utiliser dans cette situation est x=true, car c'est le plus facile à lire et à comprendre.Enfin, si l'ajout du contrôle améliore la vitesse, le compilateur le sait probablement déjà et le fera pour vous, donc vous ne pouvez pas vous tromper avec x=true (c'est pourquoi vous devez désactiver les optimisations avant d'exécuter le profileur).


Réponse:

La seule vraie façon de comprendre cela est par le profilage. Vous pouvez trouver que le test 0 (x == false) ne prend pas du tout de temps, et par conséquent il vaut la peine d'inclure en raison du temps qu'il économise lorsque x s'avère être vrai. Ou vous pouvez trouver que le test prend assez longtemps pour perdre trop de temps lorsque x s'avère faux. Je pense que le test n'est pas nécessaire. C'est parce que 0-testing et d'autres opérations au niveau du bit (et, ou, etc.) sont si rapides que je les traite habituellement comme prenant le même temps élémentaire. Et si le test 0 prend le même temps qu'une opération OU (réglage sur Vrai), le test 0 est une perte de temps redondante. Le profilage pourrait bien me prouver que je me trompe bien sûr, et ma supposition est basée sur des hypothèses vagues sur les opérations au niveau du bit, donc si vous choisissez de lancer un profileur et de comprendre cela, je serais certainement intéressé par les résultats.

Questions connexes