Discussion :

[FoX_*D i E*]

Bonjour,
Je me demande quel est le plus efficace (en terme de rapidite et de clarte) entre:

(c'est ecrit style C ou Python mais ma question s'appliquent a tous les langages qui gerent les boucles et conditions)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
if(limit < 1) {
print "Error, argument 2 has to be strict positive."
return;
}

for(i=0; i < aList.length(); i++) {

if(limit){ 
myFunction(aList[i]); 
limit--;
}
else theotherWay(aList[i]);
}

ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
if(limit < 1) {
print "Error, argument 2 has to be strict positive."
return;
}
len = aList.length();
i=0;
limit = limit<len ? limit : len;

while(limit) {

myFunction(aList[i]); 
i++
limit--;
}

while(i<len){

theotherWay(aList[i]);
i++
}

Ya peut etre mieux, sinon lequel choisir ?

[Jedai]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
len = alist.length();
limit = limit < len ? limit : len;
for(i=0; i < limit; i++) {
  myFunc();
}
for(i=limit; i < len; i++) {
  theOther();
}

me semble plus clair.

Et sauf si tu as clairement identifié ce morceau de code précis comme le goulot d'étranglement de ton entière application, les considérations de performances devraient passer après la clarté du code pour ce genre de détail (aucun effet sur la complexité asymptotique, même l'effet sur les constantes ne doit pas être bien significatif...).
--
Jedaï

[el_slapper]

+1 sur ta conclusion : la clarté du code avant tout. Souvent, les goulots d'étranglement sont les accès référentiels(sauf algos d'une exceptionelle complexité), fichiers, bases...

Et pour +1 pour la lisibilité : ta solution est également bien plus efficace, c'est elle qui m'a permis de comprendre les 2 autres(C n'est pas mon langage de prédilection, loin s'en faut). L'avantage, c'est que les bornes sont clairement identifiées. L'objectif est que le lecteur ne se pose pas de questions. Sur les deux exemples de FOX, la limite bouge, et on ne voit pas immédiatement son utilité. Quand elle est utilisée en borne fixe d'un for, ça saute aux yeux.

En outre, en cas de déboguage, on se retrouve dans un cas avec deuxvariables qui bougent, et dans l'autre, seul i bouge. Ce qui facilite grandement la compréhension de la situation.

[FoX_*D i E*]

Souvent, les goulots d'étranglement sont les accès référentiels(sauf algos d'une exceptionelle complexité), fichiers, bases...

Et sauf si tu as clairement identifié ce morceau de code précis comme le goulot d'étranglement de ton entière application [...] (aucun effet sur la complexité asymptotique, même l'effet sur les constantes ne doit pas être bien significatif...).

Ouai, ca me parait bien plus sympa de presenter comme ca,

Du coups, imaginons que mon deuxieme bout de code soit remplacer par le code en deux boucle for() (disons que d'une certaine approche il sont similaires). Si on joue avec des supers grand nombre, on est d'accord que mon premier bout de code ( faire un if dans le FOR()) ca serait moins performant que les deux boucles for(). Enfin selon moi c'est logique mais peut etre que je rate quelque chose. Je chipotte peut-etre?

[Jedai]

Du coups, imaginons que mon deuxieme bout de code soit remplacer par le code en deux boucle for() (disons que d'une certaine approche il sont similaires). Si on joue avec des supers grand nombre, on est d'accord que mon premier bout de code ( faire un if dans le FOR()) ca serait moins performant que les deux boucles for(). Enfin selon moi c'est logique mais peut etre que je rate quelque chose. Je chipotte peut-etre?

Il y aurait effectivement probablement un léger avantage aux deux boucles for. Pour connaître l'exacte différence, il serait nécessaire d'assumer une certaine connaissance de l'architecture sur lequel le programme sera finalement exécuté, des coûts respectifs des diverses opérations impliquées dans le code assembleur généré par le compilateur utilisé... Ou tu pourrais faire un benchmark.
Quoiqu'il en soit la différence est mineure (sauf cas particulier) et ne vaut sûrement pas la peine de faire ton choix pour des raisons de performances, la lisibilité doit primer.

(Je répète que je parle ici d'un cas général, la question est fort différente en embarqué par exemple ou dans une portion critique d'un programme orienté performance pure)
--
Jedaï

[FoX_*D i E*]

ok, donc la double boucle for pour lisibilité ainsi que rapidité pour la plupart des cas.
Je me dirige vers des developpement qui necessite des operations sur une masse de donnees, c'est pour ca que ca m'interesse ce genre de savoir. Mais bon, je pense qu'il faudrait en fait faire des tests sur les machines utilisees au lieu de trouver l'information sur internet^^