Je me pose une question et je sais pas s'il est intéressante et si elle a une réponse unique.Est il plus rapide d'affecte une valeur a une variable ou de tester la valeur d'une variable ? Il y a sans doute des différences entre les langages et entre les types de variables.
Y a t il un document a ce sujet ?
Merci d'avance
# Pas de réponse unique
Posté par deneb . Évalué à 3.
Dans un cas l'affectation est plus rapide, et dans un autre c'est le test. L'affectation var = 1 est plus rapide qu'un test comme if (strstr(buffer, string)). Inversement, buffer = realloc(buffer, strlen(string) + 1) est une affectation mais sera moins rapide qu'un test comme if (var == 1).
Ou alors je n'ai rien compris et tu faisais en fait référence à ça :
if (ptr = strstr(buf, "string")) { ... }
et :
ptr = strstr(buf, "string");
if (ptr) { ... }
Ici, c'est pareil au niveau du compilateur.
Il faudrait que tu précises le contexte, s'il y en a un. As tu des exemples précis dans un langage en particulier ?
[^] # Re: Pas de réponse unique
Posté par skeespin (site web personnel) . Évalué à 1.
var = 1
et
if(var != 1){
var = 1}
qu'elle va etre le plus rapide ? Je presume que c'est la premiere solution pour des langages de bas niv. (comme le C) mais est ce toujours le cas pour du java, perl ou python...
J'utilise se code dans des boucles ou il faut reinitialiser un contexte a chaque passage.
[^] # Re: Pas de réponse unique
Posté par schyzomarijks . Évalué à 3.
et
if(var != 1){
var = 1}
Ca dépend du type de variable.Si c'est un type simple, var=1 est plus rapide, mais avec les languages modernes, il faut se méfier.
si var est une propriété var=1 peut appeller une méthode set d'un objet qui peut effectuer des tas de choses (comme ouvrir une connexion, initialiser une structure...) donc, ma réponse est ca dépend :-)
[^] # Re: Pas de réponse unique
Posté par arnaudus . Évalué à 2.
À mon avis, tu n'as qu'une seule solution : 1) écrire le programme comme tu le veux, et l'exécuter avec un profiler. Si le temps passé dans ta fonction prend 0.1% du temps d'exécution total du programme, tu laisses tomber, tu vas passer des heures à optimier un truc quasiment instantané (aucun intérêt). 2) Si au contraire 50% du temps est passé dans cette boucle, alors tu peux commencer à te poser des questions. Le plus simple, c'est de tester les deux versions, et de regarder laquelle est la plus simple. Ca doit dépendre du processeur, du compilateur, des options de compilation, de la nature de la variable var et de la fréquence avec laquelle var = 1 dans ton programme (et donc peut-être des paramètres utilisés pour lancer le programme). 3) Tu choisis la version la plus rapide, en gardant à l'esprit qu'elle est plus rapide dans le contexte où tu l'as testée, et seulement dans ce contexte.
Mon impression générale, c'est que tu te prends la tête pour rien. Dans ce cas, var = 1 me semble beaucoup, beaucoup plus clair que toute tentative d'optimisation prématurée.
# ca depend...
Posté par Anonyme . Évalué à 3.
A partir de la, tout depend du nombre de cycle que consomme l'instruction d'affectation et l'instruction de comparaison.
Si tu prends un cas plus complique qui fait intervenir des fonctions intermediaires avant l'affectation ou la comparaison comme indique par deneb, tu rajoute de la complexite. Il est donc tres difficile de donner une reponse generale
[^] # Re: ça dépasse
Posté par Sisyphe Plâtrier . Évalué à 1.
Pour un cas numérique simple comme tu le poses, le problème du coût du branchement (donc du test) n'est pas négligeable puisqu'un branchement conditionnel va invalider un (voire des) cache d'instructions décodées/en décodage.
En général, on laissera quand même ce genre de détail pour une phase tardive du codage. L'optimisation bas-niveau de ce genre n'est à considérer que si c'est un morceau de code répété très très souvent et qu'une technique plus globale (cache de données, heuristique ...) ne peut en venir à bout du goulet de temps plus efficacement.
My2c
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.