ÉTUDE SUR LES BOUCLES (DO LOOP, WHILE, UNTIL)
DeadlyPredator
Messages postés
222
Date d'inscription
jeudi 15 janvier 2004
Statut
Membre
Dernière intervention
30 juin 2008
-
7 sept. 2004 à 05:07
us_30 Messages postés 2065 Date d'inscription lundi 11 avril 2005 Statut Membre Dernière intervention 14 mars 2016 - 15 mai 2005 à 19:26
us_30 Messages postés 2065 Date d'inscription lundi 11 avril 2005 Statut Membre Dernière intervention 14 mars 2016 - 15 mai 2005 à 19:26
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/25985-etude-sur-les-boucles-do-loop-while-until
https://codes-sources.commentcamarche.net/source/25985-etude-sur-les-boucles-do-loop-while-until
15 mai 2005 à 19:26
IL y a qlq jours, j'ai effectué exactement ce genre de tests sur les boucles, et mes conclusions sont en accord avec ce que j'ai lu "optimisation loop.hmtl"...
A savoir :
Avec une boucle avec DO, il est préférable de mettre la condition UNTIL ou WHILE à LOOP... La différence est assez importante...
De plus, j'avais testé les boucles FOR TO NEXT et WHILE...WEND... Les conclusions c'est que FOR TO NEXT est le plus rapide de tous... (mais bien sur ne peut pas remplir d'autre condition que l'égalité, contrairement aux autres boucles)... LA boucle WHILE...WEND était la dernière... J'ai même utilisé une structure avec GOTO + étiquette, et j'ai obtenu les mêmes résultats qu'avec WHILE...WEND...
DONC, j'en ai conclu, pour avoir toutes les possibilités de faire des boucles, d'utiliser en priorité la boucle FOR..TO..NEXT lorsque cela est possible. Puis vient les boucles DO...LOOP (UNTIL/WHILE). Normalement, on n'a pas bessoin plus... Ces dernières permettent de répondre à tous les cas de figure...
Maintenant, mes tests étaient fait à vide (en quelques sorte). C'est à dire que je m'avais mis qu'une somme à incrémenter, avec S=S+1... ET, c'est là qu'il faut tout nuancer. Car ensuite, j'ai appliqué ma petite recette à des petits vrais programmes, avec test du temps... ET, conclusion ! complètement opposé (ou presque)... En fait, dans certains cas, c'était un poil mieux, dans d'autres pire !... Alors quoi penser ? ... néanmoins, j'écarte la possibilité qu'un processus externe soit venu modifier les résultats, car j'ai testé plusieurs fois en alternance, donc impossible qu'une interférence s'applique justement seulement sur un test précis... Pour l'instant, je pense qu'il faut optimiser selon le code en présence, mais rien m'assure que cela soit le meilleur sur un autre PC... sauf, que le test effectué ici, est en accord avec ceux que j'avais réalisés, donc pourquoi pas conclure que l'optimisation du code sur un PC le soit aussi sur tous les PC ?
ENFIN, bon... c'était juste un témoinage...
Amicalement,
Us.
10 sept. 2004 à 15:40
D'accord, ça fait déjà 3,279785FF, mais quand même !
15€, là d'accord, c'est de l'arnaque... mais 10€ pour 9.50€... c'est juste pour le principe, j'espère ?
En tous cas, je vais essayer de m'acheter ça rapidos vu que ça a l'air bien et que je vais en avoir besoin... (développement d'un module en C++ avec la meilleure optimisation possible : l'ASM, bien sur)
10 sept. 2004 à 12:40
@+
10 sept. 2004 à 11:55
Et au bon plaisir de la revoyure (rediscutaille plutôt, mais bon) !
10 sept. 2004 à 11:50
10 sept. 2004 à 11:30
Est-ce que tu sais où je pourrais récupérer une masse de doc (la plus précise et complète possible) sur tous les mnémoniques et leur "effet" (histoire de mettre un peu à jour mes connaissances...)
(N'importe qui peut bien sur répondre à cette question, elle n'est pas exclusivement réservée à BruNews !)
10 sept. 2004 à 11:16
10 sept. 2004 à 11:00
Par contre, t'es sur que DEC place les flags tout seul comme un grand ?
Dernier petit détail : pour reprendre la remarque d'EBArtSoft, utilise plutôt JBE ou JNA que JNZ (des fois que ECX=0 dès le départ)
9 sept. 2004 à 16:12
Bon comme tout le monde y va de son petit test voici le mien :
'---------------------------------------
' Pour le code suivant :
'---------------------------------------
Dim i As Long
i = 10
Label1:
Call Test 'Fonction contenant un doevents
i = i - 1
If i Then GoTo Label1
'--------------------------------
' Voici le code asm :
'--------------------------------
00040 e8 00 00 00 00 call Test
00045 be 09 00 00 00 mov esi, 9
$L25:
0004a e8 00 00 00 00 call Test
0004f 4e dec esi
00050 75 f8 jne SHORT $L25
Le compilo a même abregé mes souffrances en ajouant un premier appel a "Test" avant de faire la boucle il est sympa non ? Bon aller treve de plaisanteries on a tout de même plein de projets en attente.
Pour le resultat : no comment
@+
9 sept. 2004 à 15:58
debut:
// traitement(s)
loop debut // boucle jusqu'à ce que ECX = 0
C'est une boucle du siecle dernier.
Depuis le Pentium:
debut:
// traitement(s)
dec ecx
jnz debut
est nettement plus performant.
9 sept. 2004 à 15:21
Mais si tu mets une valeur en dur dans ECX, il faudrait être idiot pour mettre 0... avoue-le !
Par contre, si tu récupères une valeur quelquonque (par exemple dans un registre ou dans la pile, ou même ailleurs), tu peux effectivement tester cette valeur.
Merci quand même de la remarque !
9 sept. 2004 à 13:12
@+
9 sept. 2004 à 13:03
Effectivement, la boucle FOR n'existe PAS en ASM
(Merci MadLucas, tu as tout à fait compris ce que je voulais dire !)
Pour plus de détails, une boucle for est codée comme suit en ASM :
mov ECX, <nb itérations> // Initialisation du compteur
debut: // étiquette de début deboucle
// traitement(s)
loop debut // boucle jusqu'à ce que ECX = 0
Ce qui est plus rapide que
mov ECX, <nb itérations>
debut:
// traitement(s)
dec CX
cmp CX, 0
jnz debut
...qui est une implémentation possible pour
i=<nb itérations>
Do
' Traitements
Loop Until i=0
(Remarque : VB ne le fait surement pas comme ça...)
Voilà... j'espère que cette petite explication sera profitable à un maximum de personnes.
Bonne prog à tous !
8 sept. 2004 à 22:31
N'oubliez pas que les premières versions de VB etait en 16 bits, dans la version 4 notamnent on pouvait compiler en 16 ou 32 bit. On efface pas un lourd passé comme ca (ca fait que 2 numéros de différence entre 6 et 4). 16 bits ca fait 2 octets, soit un integer.
Pour répondre a la question quel est le mieux , sans aucun doute des longs. Pour info dans VB .Net les entiers courts n'existe plus je crois, ou du moins les integer sont devenu des long de 4 octets et les longs de 4 des longs de 8 octets.
La différence n'est sensible en réalité qu'en terme de structure de base de données.
Les Bytes eux sont tres utile pour travailler sur des fichiers séquentiels. Dans tous les autres cas autant typer en Long.
8 sept. 2004 à 22:28
Je te suggère d'utiliser le type LONG pour les raisons suivantes:
- Les LONG sont plus stable que les INTEGER. Par exemple, dans une boucle de test, GetThickCount renvois la même valeur à chaque fois avec un LONG mais change de valeur avec un INTEGER.
- Les types LONG peuvent plus facilement être utilisés avec des appels API. Attention, les LONG doivent être changés par des INTEGER dans VB7 avec les appels API.
- Les BYTES, INTEGERS, BOOL utilisent moins de mémoire. Cependant, Win32 est 32bits et le type LONG est forcément plus rapide. Si tu utilises un INTEGER, Win32 doit le reconvertir pour le traiter.
Mais bon, les différences sont vraiement très minime entre un INTEGER et un LONG. De changer les types INTEGER pour LONG ne va pas optimiser pour la peine la vitesse de l'application. Cependant, de déclarer des INTEGER à la place des LONG quand c'est possible résuit de moitié la mémoire nécessaire. Donc, "stick with the INTEGER" en VB6 quand c'est possible, l'optimisation mémoire ici donnera de meilleurs résultats que l'optimisation "vitesse" avec le LONG.
MadLucas
8 sept. 2004 à 21:49
8 sept. 2004 à 21:42
Une question: en règle générale, est il mieux de déclarer i as Long ou as Integer ?
En ce qui me concerne je déclare systématiquement as Long, mais je suis toujours étonné de voir que MS déclare la plupart des entiers comme Integer (typiquement dans la procédure event d'un array de controles, Index est toujours un Integer).
8 sept. 2004 à 20:54
1- [ PROLOGUE (mise en memoire des elements a recuperer après execution de la fonction)]
2- [ PREPARATION DE LA FONCTION (initialisation des variables d'execution]
3- [JMP non conditionel vers _vbaOverFlow]
4- [SUITE DU CODE ... (qui ne sert a rien en fait puisqu'il jump directement vers une erreur)]
5- [EPILOGUE]
6- [RET (fin de la fonction)]
7- [GESTION DES ERREURS ("_vbaOverFlow" en l'occurence)]
en fait je pense qu'il ecrit le code quand meme car il peut toujour y avoir un "On Error Resume Next" qui permet de continuer d'executer le code a la suite d'une erreur...
Pr info, en VB la boucle for ...next est plus longue a executer car elle necessite l'utilisation de la VM (virtual machine) et notamment des fonctions __vbaVarForInit o debut, puis _vbaVarForNext à chaque execution de la boucle... alors que la fonction While utilise les simple instruction assembleur de saut & de saut conditionnel ... Voili voilou...
@++
w@rning
8 sept. 2004 à 20:30
Oh mais j'y pense, un projet est fourni avec la MSDN qui permet de tester differente methode d'arriver au meme resultat et compare les vitesses necessaires.
Je pourrai faire un autre post mais si tu (DeadlyPredator) me donne ton mail je peux te l'envoyer pour que tu l'ajoute et qu'il complete ta source, cela pourrai etre interressant.
Voila ++
8 sept. 2004 à 20:26
For.. Each.. Next c'est pour les collections d'objets et ça ne remplace pas un For.. Next.
Par exemple,
For Each BUTTON in FORM
TODO
Next
FORM et BUTTON sont des objets.
Alors que,
For x& = 0 to 100
TODO
Next x
Là c'est une boucle de 101x. C'est numérique et x est une variable de type LONG, ce qui est très différent d'un OBJECT.
MadLucas.
8 sept. 2004 à 20:19
Type de donnée numérique Vitesse
Long La plus rapide
Integer
Byte
Single
Double
Currency La plus lente
Par contre 255 * 255 = 65 025 alors que le type Long prend jusqu'a 2 147 483 647. Donc la je vois pas j'ai fais le test avec d'autres types et toujours pareil. Si qq1 a une explication.
Enfin, voici un autre extrait de la MSDN concernant les boucles :
La possibilité de définir et d'utiliser des collections d'objets est un des points forts de Visual Basic. Les collections sont très utiles mais vous devez les utiliser à bon escient pour obtenir les meilleures performances :
Utilisez l'instruction For Each...Next, plutôt que l'instruction For...Next.
Évitez d'utiliser les arguments Before et After lorsque vous ajoutez des objets à une collection.
Utilisez des collections à clés plutôt que des tableaux, pour des groupes d'objets du même type.
Les collections permettent d'itérer sur elles-mêmes à l'aide d'une boucle entière For...Next. Toutefois, la structure For Each...Next est plus lisible et, dans beaucoup de cas, plus rapide. Comme l'itération For Each...Next est mise en œuvre par le créateur de la collection, la vitesse réelle varie d'un objet de collection à l'autre. Cependant cette itération est rarement plus lente que l'itération For...Next car la mise en œuvre la plus simple est une itération For...Next de style linéaire. Dans certains cas, comme le créateur de la collection peut utiliser une mise en œuvre plus complexe qu'une itération linéaire, l'instruction For Each...Next peut s'avérer beaucoup plus rapide.
La page est assez longue mais interressante, tapez "optimisation du code" dans la case rechercher et vous aurez tout.
Bonne prog
++
8 sept. 2004 à 19:47
Le moteur de VB suppose le type d'une valeur numérique dans l'interprétation de son code. Dans l'exemple que tu donnes,
Dim i as Long
i = 255 * 255
VB considère "i" comme un LONG mais il considère aussi "255" comme un SHORT integer (-32,768 et +32,767). Lorsqu'il fait le calcul, malheureusement il fait la logique suivante:
SHORT(255) * SHORT(255) = SHORT(OVERFLOW) --> LONG(i).
Donc le résultat du calcul est temporairement placé dans un SHORT, ce qui occasionne le OVERFLOW et seulement ensuite il le place dans le LONG.. Étant donné que VB rencontre une erreur (overflow) et bien le résultat ne sera jamais placé dans la variable "i".
Maintenant, pour réussir ce calcul, il s'agît de prendre VB par la main et de lui montrer comment il doit faire ce calcul. La solution est:
Dim i as Long
i = CLNG(255) * CLNG(255)
La commande CLNG() va forcer VB à considérer la valeur "255" comme une valeur du type LONG INTEGER. Ce procédé est appellé "casting" par les codeurs C/C++.
Maintenant, avec la solution, VB interprètera le calcul de la façon suivante:
LONG(255) * LONG(255) LONG(65025) --> LONG(i 65025).
Voilà,
MadLucas (dit aussi le démistifieur.. ;-))
8 sept. 2004 à 19:25
Tu dit:
"... Vous saviez qu'une boucle For est plus rapide avec un Integer qu'avec un Byte (sisi essaie donc avec 5 boucles imbriquées de 0 à 255) alors qu'un byte prend moins de place en mémoire ? Va savoir pourquoi... "
Et bien la réponse est la suivante, le processeur calcul avec des LONG, et les integer de VB sont des modèles SHORT plus proche du LONG que peut être un BYTE.
Lorsque tu utilises un BYTE, le processeur doit le reconvertir en LONG pour faire la boucle, ce qui est un tantinet plus long.
Fait ce test, utilise un LONG à la place du INTEGER. Dans la plupart des cas, le LONG va être soit équivalent, soit plus performant.. Et en plus, il sera beaucoup plus stable que le INTEGER car il n'a pas besoin d'être converti.
MadLucas
8 sept. 2004 à 18:58
Dim i as long
i=255*255
Voila juste cela
Bonne chance
8 sept. 2004 à 18:42
Quand tu veut comparer deux choses il faut que ces deux choses soit dans les même conditions.
Donc avec les même éléments perturbateurs.
Et donc pour être sur que les deux parties de ce test soient jouées dans les mêmes conditions et à défaut de pouvoir être certain que rien ne viennent perturber soit l'un soit l'autre, la seule solution c'est de revenir à un état le plus proche du neutre (cf les solutions que j'ai déja énuméré plus haut).
Petite comparaison bien qu'un peu eloignée :
Irai tu à comparer la tenue de route d'un véhicule (A) sur autoroute par temps sec, avec 0 % de vent,etc...
avec un autre véhicule (B) qui lui roule lui aussi sur cette même route mais par temps pluvieux avec un fort vent latéral.
Soit:
Véhicule (A): Code partie 1
Véhicule (B): Code partie 2
Pluie du véhicule (B): Process ou services consommateur de CPU
Vent latéral du véhicule (C): Idem
Donc SVP messieurs lors de tests de comparaisons quels qu'ils soient, essayer de mettre ces deux éléments le plus possible dans les même conditions avant d'annoncer quelques résultats que ce soit.
Par avance merci.
8 sept. 2004 à 18:37
8 sept. 2004 à 15:29
En effet, le FOR c'est du haut niveau.. je crois que Monsieur voulait dire plutôt "le code ASM généré par un FOR en VB".
Pour le GOTO, j'ai déjà testé. J'ai pas les chiffres, mais en gros, le GOTO est remplacé par un JUMP en ASM et c'est le plus rapide selon moi. Le vrai problème avec le GOTO dans le code source c'est qu'il n'a pas de structure logique et qu'il renvois n'importe où dans le code. C'est "anti-OO" et c'est un manque dans un bon design. Cependant, je suis d'avis qu'un GOTO bien placé dans une même fonction et qui réfère à une étiquette (et non un numéro de ligne) peut optimiser, voir même faciliter un code. Mais bon, c'est de dernier recours car le GOTO est vide de sens et ne sert souvent que son concepteur.
De plus, il n'existe aucune situation où le GOTO est indispensable et il peut facilement être remplacé par un code mieux structuré qui facilitera la conceptualisation "OO".
MadLucas
8 sept. 2004 à 14:29
8 sept. 2004 à 13:33
une instruction FOR ?
@+
PS : personne n'a montré de teste utilisant le GOTO
j'aimerais bien voir le bench [;)]
8 sept. 2004 à 13:24
Mais il ne faut point oublier que la sorcellerie n'est que de la sorcellerie...
Et la prog, c'est pas d'la sorcellerie (quoique !) c'est juste quelquechose de magique ! (OoooooOOOoooooh... je serais presque poète, moi, des fois)
(Précisons que VB n'est pas magicien, il est juste un peu... bizarre)
8 sept. 2004 à 13:14
Vous savez que, en ASM du moins, la boucle la plus rapide est le FOR ?
Moi, je serais d'avis qu'on compare au moins une fois les performances d'un FOR.
C'est d'ailleurs ce que j'ai fait pour vous (mais aussi pour moi).
J'ai réalisé ce test avec lngDuree = 1000000000 (1 milliard) sur un Windows 2003 Server avec un bi-processeur 2x2,8GHz (bah, désolé mais j'avais pas moins puissant sous la main, alors...)
Séquence 1 :
lngLastMesure = GetTickCount
Do
I = I + 1
Loop Until I = lngDuree
MsgBox GetTickCount - lngLastMesure
Séquence 2 :
lngLastMesure = GetTickCount
For I = 1 To lngDuree
Next
MsgBox GetTickCount - lngLastMesure
Et maintenant.............
LE résultat :
1094ms pour le Do...Loop (résultat assez stable)
1500ms pour le For...Next (résultat fluctuant)
Ma conclusion :
VB n'a pas l'air très doué en optimisation de rapidité...
Je pensais honnêtement que le for serait le plus radide. Quelle ne fut pas ma déception...
En espérant que ce petit test soit profitable à tout le monde, je souhaite à tout le monde "Bonne Prog !"
FKX
8 sept. 2004 à 12:33
8 sept. 2004 à 12:27
8 sept. 2004 à 04:01
8 sept. 2004 à 01:48
Fait rouler ton code dans une boucle pendant une nuit et tire une conclusion à partir d'une moyenne. PLus tu as de résultats dans ton calcul moyen, plus tu te rapprocheras de la réalité.
Autre truc... Compile et observe le code assembleur avec un debugger.. la plupart du temps, on peut connaître la vrai performance d'une boucle en comparant son code compilé.
Et finalement, tu dois faire ton test sur une application compilé et non et interprétation (Run) .. Seul le .exe est valable.
MadLucas
7 sept. 2004 à 14:11
do while i <> ??
i=i+1
loop
et là, à chaque cycle VB fait do..., i=i+1, loop donc 3 lignes mais quand j'ai inversé la position de la condition, vb fit la ligne do seulement au début puis après il ne la fait plus. Il effectut seulement le i=i+1 et loop while i <> ... donc cela doit aider dans la vitesse du code.
7 sept. 2004 à 13:20
Désolé mais mais comment peut tu être aussi affirmatif avec des résultat qui quoi que lancer successivement dans le même code, ne peuvent en aucun cas être comparé.
Je m'explique :
Commen peut tu être certain que ton processeur n'est pas utilisé par une appli ou un service est entre deux.
Non mais franchement, ce genre de test au résultat foireux , tu peut l'exécuter autant de fois que tu voudras tu n'obtiendra jamais les même résultat.
Et dans le meilleur des cas tu n'a qu'a inverser l'ordre de tes comparaisons et là, tout tombe à l'eau.
Désolé mais cela n'apporte pas d'eau au moulin VB.
7 sept. 2004 à 08:48
Mais comment j'ai pus vivre autant de temps
sans savoir ça ?"
Petite suggestion Si j'ecris ceci :
Do While True
'Traitement de chaine
Loop
ou ceci :
Do
'Traitement de chaine
Loop While True
Mes cycles sont perdu a 99% dans le traitement de chaine parce que VB appel plus de 1000 fois la VM avant faire la moindre operation je gagne combien
de cycle en intervertissant While True au debut et
a la fin ?
Tu aurais du mettre cette page dans un tutorial ya une belle rubrique toute neuve fait pour ça. Car la je vois pas trop ce que ça fait ici. Au moins l'intention est bonne...
@+
7 sept. 2004 à 05:07