6
votes

Qu'est-ce qui est mieux? Si..ele ou multiple simple si

Parler de la performance Java .. Qu'est-ce qui va mieux? Si..elez ou multiple simple si xxx

ou xxx

intéressé par vos pensées

thnx!


6 commentaires

S'il y a une différence de performance, il est probablement négligeable.


Je ne suis pas expert, mais je serais surpris s'il y avait une différence - mais la réponse à toutes les questions de performance est "Essayez-la vous-même et de voir". (Et l'autre réponse est «Ce n'est probablement pas votre goulot d'étranglement».) Ceci ressemble à un de style question.


Peu importe "quelque_code", seulement comment Java exécute "si" déclaration


Vous pouvez également choisir d'avoir un seul retour à la fin du si ... sinon si .. exemple.


Supposons que les valeurs de retour pourraient être différées


Je reste à l'écart de Elsesif / sinon si pour lisababe. Et essayez de vous tenir à une déclaration de retour à la fin de la fonction. Principe: 1. Obtenez l'entrée, 2: Faites le calcul, 3: renvoyer la sortie.


5 Réponses :


0
votes

Je suis confiant un seul si serait meilleur, car chaque fois qu'une condition vraie est rencontrée, il peut sauter en toute sécurité les autres car ils ne seront pas réalisé. Si vous avez utilisé plusieurs si S, toutes les conditions ultérieures devraient être évaluées de toute façon (même si, comme je pense que vous pensez que vous supposez, ils se seraient mutuellement exclusifs).


5 commentaires

Mais dans l'exemple, ils ne vont pas être exécutés de toute façon parce que la fonction revient avant qu'elles soient atteintes.


N'a fait de différence dans cet exemple de toute façon, car il existe une instruction retour dans chaque si corps.


Mais cela peut le faire quand même en raison du formulaire de construction «retour».


Oui, mais si "mieux" == 1ms plus vite, qui va remarquer?


A manqué le renvoie . Il ne devrait y avoir aucune différence de performance significative. Aller pour la lisibilité du code;)



16
votes

Il n'y a pas de différence, de performance sage. Choisissez l'option la plus lisible, ce qui pourrait être soit en fonction de ce que le code fait.

En général, ne vous inquiétez pas de ces micro-optimisations. L'optimisation ne devrait venir qu'après avoir déterminé qu'il existe un problème de performance qui doit être corrigé.

"Nous devrions oublier les petites gains d'efficacité, dire environ 97% du temps: optimisation prématurée est la racine de tous mal." -Donald Knuth


0 commentaires

1
votes

Le si ... EXEMPLE EXEMPLE QUE VOUS DÉPONSEZ PAS N'EST PAS BESOIN DE LA RETOUR S Si cela se trouve dans une fonction sans retour. Dans ce cas, le si ... sinon sera plus facile à lire.

En outre, le si ... d'autre devrait être préféré car il est explicit que ces cas sont mutuellement exclusifs.

S'il y a une différence de performance ici, votre compilateur / interprète est nul.


2 commentaires

S'il y a une différence de performance, le compilateur suce.


Pourrait être l'interprète, pour une langue interprétée.



0
votes

dépend de la situation.

Si les conditions sont mutuellement exclusives, utilisez sinon . Cela causera que Java ne vérifie aucune des conditions après que celle qui se trouve soit vraie.

S'ils ne sont pas mutuellement exclusifs, utilisez une liste de si sans que plusieurs cas puissent se produire plusieurs cas.

Dans votre cas, avec des retours dans chacun, la performance sera identique car le même nombre de comparaisons devra être fait, peu importe quoi.


1 commentaires

Cela ne fera aucune différence si les conditions sont mutuellement exclusives. (Cela ferait un s'il n'y avait pas de retour dans chaque clause de "puis" ...)



0
votes

Je ne vous soucierais pas de la performance ici autant que la lisibilité et la maintenabilité du code. Comme mentionné, la performance sera essentiellement identique après la compilation du code.

Il est de mes préférences d'être plus explicites sur mes conditions, au lieu de permettre un comportement d'être implicitement «tomber».

En outre, le célibataire si ne sera pas évalué plus rapide que le si sinon. Le chemin d'autre ne sera jamais vérifié si le cas est vrai.


0 commentaires