COURS OPTIMISATION DU CODE VB AVEC PROGRAMME DE TEST
cobra84
Messages postés
42
Date d'inscription
dimanche 26 août 2001
Statut
Membre
Dernière intervention
13 août 2007
-
6 août 2002 à 15:34
cs_mehdibou Messages postés 365 Date d'inscription vendredi 24 mai 2002 Statut Membre Dernière intervention 18 octobre 2004 - 18 août 2003 à 18:19
cs_mehdibou Messages postés 365 Date d'inscription vendredi 24 mai 2002 Statut Membre Dernière intervention 18 octobre 2004 - 18 août 2003 à 18:19
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/4234-cours-optimisation-du-code-vb-avec-programme-de-test
https://codes-sources.commentcamarche.net/source/4234-cours-optimisation-du-code-vb-avec-programme-de-test
18 août 2003 à 18:19
23 janv. 2003 à 08:58
juste pour le plaisir : BRAVO !!!
15 nov. 2002 à 19:59
@+ et bonne prog!
15 nov. 2002 à 14:37
15 nov. 2002 à 11:05
C vrai qu'un forum sur l'optimisation serait le bienvenue.
au fait, tu pourrais créer un programme qui optimise automatiquement le code généré par notre pauvre cerveau, non ?
8 août 2002 à 16:56
@ Brushttiii Pok ;-)
8 août 2002 à 13:01
Bon... je vais voir ce que je peux faire avec Right et Left...
Excellente idée !!!
@+
8 août 2002 à 08:54
Aller @+
7 août 2002 à 23:25
7 août 2002 à 22:38
7 août 2002 à 22:33
7 août 2002 à 22:27
7 août 2002 à 17:15
7 août 2002 à 16:26
7 août 2002 à 16:25
Et les gars siou plait, faites gaffe à l'orthographe please ...
Merci à toi cobra84
7 août 2002 à 11:29
@+ ;-)
7 août 2002 à 08:54
Lors de l'utilisation d'un recordset (avec ADO, DAO). Il vaut largement mieux utiliser une boucle For Next que faire une Do Until EOF.
Exemple:
Do Until MyRs.EOF
Me.Text1.Text = MyRs.Fields(1).Value
MyRs.MoveNext
Loop
EST BEAUCOUP PLUS LENT QUE
Dim RecCount As Long
Dim I As Long
MyRs.MoveLast
MyRs.MoveFirst
RecCount = MyRs.RecordCount
For I=1 to RecCount
Me.Text1.Text = MyRs.Fields(1).Value
MyRs.MoveNext
Next I
La 2e façon de faire est plus rapide que la première. Ceci est du au fait qu'il n'y a pas de vérification de fin de fichier à chaque passage dans la boucle. Ceci est surtout probant pour des jeux d'enregistrements conséquents, comme pour beaucoup d'autres exemples.
Certes la 2e façon de faire est plus longue en code, mais sachez qu'en VB, le code le plus court n'est pas forcément plus rapide à l'exécution.
Les instructions du type: IIF, CHOOSE, SWITCH, REPLACE,... sont très certainement plus lentes que si on les avait écrite nous mêmes. Mais c'est vrai qu'à l'écriture du code, c'est beaucoup plus rapide à 'pondre'.
J'ai lu aussi qu'il était plus judicieux d'utiliser des variables de type LONG au lieu de l'INTEGER. VB6 fonctionnant en 32 bits, celui-ci serait plus optimal avec la gestion du type LONG, ce qui me correct comme raisonnement.
Bonne prog à toutes et àtous...
NéoB
7 août 2002 à 08:34
@+ et bonne prog ;-)
7 août 2002 à 01:35
autre idée
comparer les différente boucle pour une nombre (textbox) fois: do, while, for
connaitre la quantité de mémoire utiliser pour l'exécution (il y a un exemple sur le site pour un utilitaire de gestion de pc, faudrias inclure le code avec une option on/off pour pas trop influencer la vitesse)
l'utilisation de certain ocx comme image ou picture
les différent trie avec une nombre (textbox) de donné
la différence de temps et de mémoire entre des if imbriqué ou un select case
s,il vaut mieux inclu une image dasn un programme vb ou de le loader au démarrage.
le gain de temps de mettre des images en mémoire au lieu des reloader à chaque fois (de toute façon, avec la mémoire qu'on possède sur nos oridnateur, mettre en mémoire, ça change pus grand chose à comparé lire sur le disque qui est très long)
utilisation du timer au lieu de l'API (J'ai toujours utiliser le timer, mais il me semble qu'il y a un API aussi)
les différence entre les type de compilation possible small code ou fast code
les différente option possible non nécessaire pour certain programme lorsqu'on le met en .exe
mettre tout les texte affiché dnas un fichier texte, le loader au démarre pour afficher tout les texte dans le programme prend t'il plus de temps que de tout mettre les texte directement dans VB (ça serait pratique à connaitre pour les logiciel multilangue, si on perd pas trop de temps à l'exécution du programme)
utilisation d'un if pour savoir si on dois faire une action aulieu de l'exécuter est t'il plus rapide. exemple: avec les api getpixel et setpixel, on peut inversé l'image de l'écran de l'ordinateur. Est t'il plus justicieux d'intervertir tout les pixel ou de faire une validation si les 2 pixels sont différent avant de changer (desfois ajouter un petit if, peut accélérer grandement un programme, comme dans ce cas, intervertir 2 pixels identiques, ça fais pas grand chose).
faudrait un exemple, mais j'en ai pas en tête. Utiliser un code extrêment court est pas toujours le plus rapide. mieux vaut faire une boucle mixer avec des if, que de faire pliens de boucle imbriqué.
là, j'ai pus d'idée de d'autres test. J'ai pas le temps de le coder, donc faudrait que quelqu'un le fasse, ça pourrais en aider beaucoup.
7 août 2002 à 01:27
c bien ce prog!! 10/10
6 août 2002 à 21:47
Merci :)
6 août 2002 à 18:29
Par contre je ne savait pas pour les méthodes Right, Left.... !!!!! (je vais tester)
Pour le with, c'est vrai qu'il est plus rapide (et plus propre) mais il m'est arrivé de voir des lignes de codes ignorées (sauf en pas à pas). Dans ce cas, j'utilisai une l'objet Selection de Word.Application. (Word2K)
Merci :)
6 août 2002 à 16:18
Aller @+ ;-)
6 août 2002 à 15:43
@+
6 août 2002 à 15:34
@+ et Bonne Prog ;-)