begin process at 2008 09 06 01:01:34
1 237 606 membres
8 nouveaux aujourd'hui
14 313 membres club

Vous ne trouvez pas de réponse à votre problème ? Alors posez la question dans le forum.
Souvenez-vous qu'il n'y a jamais de question bête, mais rester dans l'ignorance parce que l'on n'ose pas poser une question, ça c'est une erreur !

OPTIMISER UN PROGRAMME EN VISUAL BASIC 6


Information sur le tutorial

Catégorie :Optimisation du code Date de création : 10/09/2006 16:53:48 Vu : 14 648 fois

Note :
10 / 10 - par 5 personnes
10,00 / 10

  • 1

  • 2

  • 3

  • 4

  • 5

  • 6

  • 7

  • 8

  • 9

  • 10

Commentaire sur cette source (22)
Ajouter un commentaire et/ou une note

Description

Ce tutoriel présente les règles et astuces élémentaires liées à l'optimisation d'un code rédigé avec Visual Basic 6. Destiné avant tout aux débutants, il ne comporte que l'essentiel et ne présente pas de justifications détaillées. Des liens sont donnés vers des pages plus complètes.

Tutorial

Optimiser un programme en Visual Basic 6

 

Qu'est-ce qu'optimiser ?

En latin, l'adverbe optime, superlatif de bene, signifie « de façon excellente, le mieux du monde ». Optimiser a donc quelque chose à voir avec l'excellence. En informatique, il s'agit bien sûr des performances. On dit qu'un programme est optimisé lorsque le programmeur a pesé une à une toutes les lignes (ou presque) de son code pour ne garder que leur écriture la plus efficace. L'optimisation est donc aussi affaire de nuances. Ce tutoriel se veut une brève introduction à l'optimisation avec Visual Basic 6.

 

Optimiser n'est pas suffisant

La chose la plus importante de ce tutoriel tient en une phrase : l'optimisation ne remplace pas la réflexion. Pourquoi ? La réponse est simple. Lorsque vous rédigez un programme et que vous en venez à évaluer ses performances, vous verrez que certaines parties sont cruciales en termes de performances. En règle générale, il ne suffit pas d'optimiser ces parties pour obtenir de bonnes performances. Il faut aussi, et avant tout, s'assurer que l'algorithme utilisé est raisonnable. Cela passe souvent par une analyse (ou même une évaluation approximative) de sa complexité en temps et / ou en mémoire. Par exemple, un banal tri par insertion, qu'il soit brut ou optimisé, sera toujours beaucoup plus lent qu'un tri rapide, même programmé par un cochon. Ceci dit, ne me faites pas dire ce que je n'ai pas dit : l'optimisation n'est pas sans effet, bien au contraire ! Nous allons d'ailleurs voir ce qu'elle peut nous apporter par la suite.

 

Optimiser n'est pas défigurer

Autre chose importante, si les programmes ne s'écrivent qu'une seule fois, ils sont en revanche souvent lus, aussi bien par le programmeur lui-même que par des tiers. De fait, l'optimisation doit toujours être vue comme un compromis entre accroissement des performances et lisibilité du programme. En d'autres termes, il peut être judicieux d'ajouter des commentaires là où des optimisations ont été effectuées, surtout lorsqu'elles introduisent une manière de faire peu « naturelle » ou non « immédiate ». Songez bien que si cela ne vous a pas paru évident, cela l'est probablement encore moins aux yeux du programmeur qui découvre votre code.

 

Quand optimiser ?

Dernier point avant d'aborder l'optimisation proprement dite : quand faut-il optimiser son code ? A l'évidence, il n'existe pas de règle infaillible pour répondre à cette question. En revanche, on se tire d'affaire sans problème en réfléchissant un peu : certaines optimisations devraient devenir des réflexes (je pense notamment aux déclarations, au symbole dollar, etc... dont je vais parler plus loin) et se retrouver partout, alors que d'autres peuvent très bien être considérées comme facultatives lorsque le programme ne se doit pas d'être particulièrement efficace (sauf erreur, tous les programmes n'ont pas besoin d'être des bêtes de course... surtout en Visual Basic).

 

Quelques règles pour optimiser

Maintenant que cette longue et pénible introduction est terminée, nous allons pouvoir parler de choses plus concrètes. Que peut-on faire pour optimiser son code ? Je ne vais pas tout détailler pour deux raisons : d'une part ce serait trop long, et d'autre part il faudrait que j'en sache beaucoup plus sur Visual Basic. Nous allons donc nous contenter des notions élémentaires.

 

Le langage

Certes, s'agissant de VBFrance, nous allons parler d'un langage, Visual Basic. Cela dit, il n'est peut-être pas inutile de rappeler qu'il existe des langages plus rapides que d'autres, car leurs compilateurs sont plus performants. Par exemple, les trois versions d'un même programme « bien rédigé », l'une en C, l'autre en Java et la troisième en Visual Basic, ne nécessiteront pas le même temps d'exécution sur une même machine. Cela dit, laissons tomber ce point qui ne rentre que partiellement dans le cadre de ce site consacré à un langage particulier et venons-en à l'essentiel.

 

Typage

Contrairement à ce que l'on pourrait croire, il ne suffit pas de déclarer « As Integer » un ensemble de variables pour que toutes soient définies comme des entiers. Même si cela peut paraître rébarbatif, il faut déclarer toutes les variables. Par exemple :

   Mauvaise écriture :

Dim Minimum, Maximum As Integer

   Ecriture correcte :

Dim Minimum As Integer, Maximum As Integer

Evidemment, ce qui s'applique aux entiers s'applique à tous les autres types. Il ne faut pas oublier que Visual Basic considère que toute variable sans type explicite est de type Variant. Avec ce type polymorphe, rien (ou presque) n'est bon : vous réduisez les performances de votre application, et vous vous exposez à de déplaisantes erreurs de typage ou, à défaut, à des conversions implicites qui pèsent beaucoup sur votre code.

 

Les mathématiques

Même si les profs de maths sont des personnes rarement adorées, la discipline qu'ils enseignent peut vous apporter une aide précieuse. Par exemple, comment savoir si un entier est pair (en anglais : even number) ? Il existe de très nombreuses manières de procéder. La première fait appel à un semblant de partie entière :

'Détermine si un nombre est pair

Public Function

IsNumberEven(Number As Long) As Boolean

   IsNumberEven = ((Number \ 2) = (Number / 2))

End Function

Cette programmation est tout simplement abominable. Sur le plan mathématique, elle relève déjà du non-sens. Si on fait de l'arithmétique sur N ou sur Z, pourquoi faire intervenir une loi de composition (dite externe) dont le résultat n'est ni dans N ni dans Z ? Allez, ressaisissons-nous et proposons autre chose. Voilà déjà quelque chose de plus inspiré :

'Détermine si un nombre est pair

Public Function

IsNumberEven(Number As Long) As Boolean

   IsNumberEven = (Number

Mod 2 = 0)

End Function

Notre nouvelle fonction IsNumberEven est certes plus performante que la première, mais est-elle pour autant la meilleure ? Hélas, la réponse est non. Il est en effet plus rapide encore de tirer parti de la propriété mathématique suivante : « tout nombre pair écrit en binaire se termine par un zéro ». C'est simple : 2 s'écrit 10, 4 s'écrit 100, 6 s'écrit 110, etc... (et cela se généralise). Allons-y donc franchement et savourons notre victoire (même dérisoire, une victoire est toujours une victoire) :

'Détermine si un nombre est impair

Public Function

IsNumberEven (Number As Long) As Boolean

   IsNumberEven = ((Number

And 1) = 0)

End Function

Il existe un autre cas relativement simple où les calculs bit à bit (ou bitwise operations pour les fanatiques d'anglais) sont plus efficaces que les fonctions mathématiques usuelles. Il s'agit du calcul des composantes rouge, verte et bleue à partir d'une entier :

'Détermine les composantes rouge, verte et bleue d'une couleur

Public Sub

GetRGBFromLong(ByVal Color As Long, Red As Byte, Green As Byte, Blue As Byte)

   Red = Color

And &HFF

   Green = (Color \ &H100)

And &HFF

   Blue = (Color \&H10000)

And &HFF

End Sub

De tels calculs peuvent parfois paraître obscurs (ils le sont sans doute pour ceux qui ne sont pas familiers avec les opérations bit à bit), mais Google est un dieu puissant et généreux... ;-) Je vous conseille tout particulièrement http://edais.mvps.org/Tutorials/Graphics/GFXch5.html (en anglais).

 

Le symbole dollar

Optimiser, c'est gagner du temps. Et le temps, c'est de l'argent. Alors pensez au symbole dollar ! Au-delà de cette blague vaseuse, il existe de nombreuses fonctions Visual Basic qui méritent d'être affublées d'un tel symbole. Cela vous permettra d'obtenir une valeur de retour sous forme de chaîne de caractères, au lieu d'un affreux Variant. Ainsi, il peut être préférable d'écrire :

Left$, Mid$, Right$, Chr$, ChrW$, UCase$, LCase$, LTrim$, RTrim$, Trim$, Space$, String$, Format$, Hex$, Oct$, Str$, Error$

Attention !

Il est inutile de transformer le recours au symbole dollar en véritable obsession. Par exemple, il est inutile d'écrire Replace$ (ou InputBox$) car Replace renvoie déjà une chaîne de caractères (ceux qui ne le croient pas n'ont qu'à regarder l'infobulle qui apparaît dans Visual Basic lors de la saisie de la parenthèse ouvrante). Maintenant, si vous trouvez que Replace$ est plus joli, je ne vais pas vous contredire...

 

Dim BadThing As New HowToMakeAProgramRunSlowly

Derrière ce titre volontairement fantaisiste se cache quelque chose qui n'a rien d'une plaisanterie. Le mot-clef « New » indique à Visual Basic que la variable déclarée doit être automatiquement instanciée. De fait, chaque fois que vous l'utiliserez, Visual Basic vérifiera si elle doit être instanciée ou non (avec toutes les répercussions que cela implique sur les performances). De plus, si vous souhaitez bien contrôler toutes les étapes, préférez :

'Déclaration

Dim Something As SomethingElse

'Instanciation

Set Something = New SomethingElse

'Libération de la mémoire

Set Something = Nothing

 

Plutôt If ou plutôt IIf ?

S'il est bien une fonction que l'on devrait apprendre à ne pas aimer exclusivement (Attention ! Je n'ai pas écrit : « à ne pas aimer tout court »), c'est bien la fonction Immediate If, mieux connue sous son nom usuel « IIf ». Non seulement cette fonction peut jouer de vilains tours à ceux qui l'utilisent (voir la source de Renfield - http://www.vbfrance.com/code.aspx?ID=33789), mais elle est aussi caractérisée par sa lenteur. Lorsqu'il est nécessaire d'optimiser son code, il vaut mieux lui préférer la structure classique. Par exemple, la fonction Min suivante :

Public Function

Min(A As Long, B As Long) As Long

   Min = IIf(A < B, A, B)

End Function

sera toujours plus lente que son équivalent :

Public Function

Min(A As Long, B As Long) As Long

   If A < B Then Min = A Else Min = B

End Function

 

Le mot-clef Like

Le mot-clef Like offre une souplesse indéniable. Certes, il n'égale pas les expressions rationnelles (loin s'en faut), mais tout de même... il est « sympa ». Seulement, là où le bât blesse, c'est qu'il est aussi plutôt lent. Autant que possible, préférez-lui les fonctions classiques associées aux chaînes de caractères (InStr, InStrB, etc...).

Une chaîne vide demande un temps plein

Les chaînes vides s'écrivent souvent sous la forme de deux guillemets disposés en chiens de faïence. C'est très court à écrire, mais c'est plus long que nécessaire. Il vaut mieux remplacer :

Dim MySlowEmptyString As String

MySlowEmptyString = ""

par :

Dim ThisIsFast As String

ThisIsFast = vbNullString

N'allons cependant pas trop vite. En réalité, la chaîne vide (empty string) et la chaîne nulle (null string) sont deux choses bien distinctes. Une chaîne vide est une chaîne, alors qu'une chaîne nulle n'est pas une chaîne. En C, vbNullString est l'équivalent de NULL.

 

Réaliser des mesures de temps

Pour effectuer des mesures exploitables, il est fortement recommandé de ne pas utiliser de minuterie (Timer), dont la précision est de l'ordre de 50 millisecondes et de ne pas effectuer vos mesures dans l'IDE mais dans un exécutable. Vous pouvez utiliser les API GetThickCount ou le duo QueryPerformanceCounter / QueryPerformanceFrequency. Dans tous les cas, il vaut mieux exécuter plusieurs fois (des dizaines, des centaines voire des milliers de fois) la fonction à l'intérieur d'une boucle plutôt que de se contenter d'un appel. A toutes fins utiles, voici leurs déclarations :

Private Type

LARGE_INTEGER

   LowPart

As Long

   HighPart

As Long

End Type

 

'Evaluer le temps d'exécution d'un programme

Private Declare Function

QueryPerformanceCounter Lib "kernel32" ( _

   lpPerformanceCount

As LARGE_INTEGER) As Long

 

'Fréquence du compteur de Windows

Private Declare Function

QueryPerformanceFrequency Lib "kernel32" ( _

   lpFrequency

As LARGE_INTEGER) As Long

 

'Evaluer le temps d'exécution d'un programme

Private Declare Function

GetTickCount Lib "kernel32" Alias "GetTickCount" () As Long

 

Conclusion

Optimiser son code n'est ni une nécessité ni un remède miraculeux . Les programmes qui reposent sur des algorithmes à la complexité aberrante seront toujours poussifs. Les programmes bien conçus n'y gagneront que s'il y a vraiment matière à gagner quelque chose. Comme toujours, la conclusion est désarmante de simplicité : un bon programme est un programme bien pensé. Voilà tout ! J'espère avoir fait quelque chose d'utile. Toutes les remarques, critiques, suggestions et corrections sont les bienvenues.

 

Bah, moi il m'en faut plus !

Ce tutoriel n'est qu'un début... Il existe sur Internet de très nombreuses pages qui vous donneront de plus amples renseignements sur le sujet. Allez voir notamment le site de us_30 et sa rubrique consacrée à l'optimisation de code VBA. Vous y trouverez des mesures comparatives de vitesse et de nombreux autres exemples. Pour les anglophones, vous pouvez consulter les pages http://www.aivosto.com/vbtips/stringopt.html (pour les chaînes de caractères), mais aussi http://www.aivosto.com/vbtips/vbtips.html (remarques générales d'optimisation), et ainsi de suite...

10 septembre 2006 17:06:53 :
Toute la mise en forme avait disparu, les apostrophes ont été remplacées par des points d'interrogation... bref j'ai remis un peu d'ordre mais ce n'est plus du tout comme l'original...
10 septembre 2006 19:59:06 :
Mise en forme... j'espère que cette fois-ci la mise en forme sera prise en compte.
11 septembre 2006 07:30:06 :
Encore la mise en forme...
12 septembre 2006 07:28:19 :
-
  • signaler à un administrateur
    Commentaire de sheorogath le 13/09/2006 19:20:21 administrateur CS

    je suis pas vbiste loins s'en faut mais je doit avouer que j'ai apprecier ton tutorial

    si tu arrive a le continuer pour les petites astuces mathematique ca pourrais devenir vraiment sympa

    allez bonne continuation

    ++

  • signaler à un administrateur
    Commentaire de econs le 15/09/2006 16:06:53 administrateur CS

    Encore un fois bien présenté.
    Le ton, le contenu, c'est très bien, les exemples pertinents et les renvois vers d'autres sources judicieux.

  • signaler à un administrateur
    Commentaire de violent_ken le 19/09/2006 21:15:21

    Salut, très intéressant tutoriel.
    Et effectivement, les exemples/astuces mathématiques sont très sympathiques (j'adore les maths).

    Une question concernant l'optimisation, quel est l'impact réel (en terme de temps d'éxecution) des options de compilation ?
    J'avais supprimé le contrôle de limite de tableau dans un code utilisant un nombre important de dynamic arrays, mais le résultat semblait identique avec ou sans cette optimisation ?

    @+

  • signaler à un administrateur
    Commentaire de Cacophrene le 21/09/2006 09:34:53

    Salut !

    Je n'ai jamais essayé de mesurer l'effet des options de compilation. C'est à voir, je verrais si j'ai le temps. En tout cas là je ne sais pas quoi répondre.

    Cordialement,
    Cacophrène

  • signaler à un administrateur
    Commentaire de joecul le 05/10/2006 12:06:14

    Au début, j'étais un peu sceptique quand j'ai lu le titre de ton tutorial.Mais, à la fin j'avoue que tes petites astuces sont assez intéressantes, pour la simple raison que quand nous développons nous ne prêtons pas attention à ce genre de "détails".Mais ceux-ci s'avèrent d'une importance capitale.Continues sur cette lancée.



    Respect.

  • signaler à un administrateur
    Commentaire de ciberrique le 07/10/2006 00:30:39

    Un truc tout bete en vb mais qui peut parfois accelerer enormement le temps d'execution c'est de transformer les divisions en multiplication.
    25/100 = 25*0.01
    Et pourtant 25*0.01 et plus rapide que 25/100.

  • signaler à un administrateur
    Commentaire de d_brahim2 le 18/10/2006 16:40:32

    Salut
    Un bon tutorial traitant un sujet très important surtout pr les projets assez grand.
    J'aimerai bien que vous parlez aussi de ce genre de déclaration:
    ---------
    Dim i%
    ---------
    Cordialement

  • signaler à un administrateur
    Commentaire de interkira le 31/10/2006 16:21:02

    Bonjour,

    Oui très intéressant, il faut dire que j'ai moi-même expérimenté l'optimisation sur un logiciel que j'ai réalisé au boulo et cela donne de très bon résultat et les utilisateurs sont contents.

    Il manque aussi l'optimisation d'écriture/lecture de fichier. Par expérience on passe très vite de 4h à 1h en faisant très peu de chose (boulets de collègues je vous jure...) sur des milliers de traitement. :D

    Cordialement

  • signaler à un administrateur
    Commentaire de Cacophrene le 03/12/2006 11:33:30

    Salut à tous !

    Je prends note de vos suggestions. Je n'ai pas le temps de continuer le tutorial en ce moment, mais des ajouts sont prévus... dans un "proche" avenir.

    Cordialement,
    Cacophrène

  • signaler à un administrateur
    Commentaire de infocher le 10/01/2007 22:36:09

    je prends note pour l'avenir

  • signaler à un administrateur
    Commentaire de jhon_smith le 04/02/2007 14:44:15

    très éducatif, merci !

  • signaler à un administrateur
    Commentaire de lermite222 le 06/04/2007 05:50:06

    Bonjour à tous.
    Un peu tard pour intervenir, mais c’est la première fois que je vient sur cette page.
    L’optimisation ne me semble plus tellement d’actualité, c’était bon, je dirais même obligatoire, avec les anciens BASIC interpréteur, où le gain de temps pour chaque optimisations se chiffraient en seconde(s), mais maintenant que l’exécution d’une procédure appelant parfois quelque dizaines de routines ou de fonctions dure 1,2 centième de seconde  à la place d’ 1,1 centième, je n’y vois pas beaucoup d’intérêt.
    De plus, dans certain cas le code risque d’être moins compréhensible.
    Le bon exemple est donné plus haut 25/100 = 25*0.001
    1°) le calcul 25/100 peut être effectué avec 2 variables integer, le résultat éventuellement dans une variable single, dans le cas de la multiplication il faudrait au moins 2 variables single
    or il est bien connu que les calculs sont relativement plus rapide en integer qu’en single.
    2°)En supposant que le diviseur soit saisi par un utilisateur il faudrait d’abord diviser sa saisie par 100 … où est le gain ?.
    Je dirais donc, pas mal mais obsolète.
    Cordialement lermite222

  • signaler à un administrateur
    Commentaire de Cacophrene le 13/04/2007 18:37:29

    Salut !

    L'optimisation n'a pas lieu d'être pour des calculs de routine ou des applications classiques. Elle n'est utile que dans le cas de traitements lourds. En VB notamment, langage déjà lent, c'est alors plutôt intéressant (par exemple exécuter très souvent un Select Case aura un impact significatif sur le temps d'exécution, par rappot à un If...Then...Else, etc...). Mais si les performances sont cruciales, évidemment, on changera de langage.

    Autre point, j'aborde un peu le typage avec le symbole '$'. Certes VB est un langage très souple, mais il n'est pas toujours mauvais d'être rigoureux et d'obtenir une chaîne plutôt qu'un variant. Pour être aussi un utilisateur de OCaml, où les conversions implicites de type n'ont jamais lieu, je sais que la "souplesse" joue parfois des tours.

    En fait, il faut plutôt voir ce tutoriel comme une présentation de techniques "alternatives" : voir par exemple les opérations bit à bit pour la parité d'un nombre), plutôt qu'un modulo.

    Cordialement,
    Cacophrène

    PS : Je n'ai pas répondu plus vite parce que je ne parcours que rarement ces pages ;-).

  • signaler à un administrateur
    Commentaire de Renfield le 17/04/2007 11:33:38 administrateur CS

    important, si, car sensible en VB6...

    sous pretexte que les machines "assurent", ont va pas coder comme des sagouins, compensant (négativement) ainsi l'evolution des machines...

    je dirai pas qu'il faut économiser le moindre bit, comme ça a pu être fait, mais une boucle mal concue est une boucle mal concue... elle sera lente et cela se ressentira tot ou tard.

    certains le savent, j'aime à optimiser des boucles, traitements...

    si tu regardes par exemple :
    http://www.vbfrance.com/code.aspx?ID=41453

    j'ai revu ma copie plusieurs fois, modifiant l'architecture de la chose, les gains en terme de temps de traitement s'en sont ressentis...

    les règles sont toujours les mêmes
    - limiter les accès disque
    - éviter les calculs redondants
    - éviter les calculs inutiles
    - éviter les allocations recurrentes
    - éviter les transtypages inutiles
    - typer ses variables
    - etc

  • signaler à un administrateur
    Commentaire de Cacophrene le 19/04/2007 15:40:16

    Salut !

    Oui, c'est plus ou moins toujours la même idée : faire ce qu'il faut et rien que ce qu'il faut, pour que ce soit bien bien fait.

    Cordialement,
    Cacophrène

  • signaler à un administrateur
    Commentaire de Kristof_Koder le 08/08/2007 09:33:07

    Salut ! Très bon tuto en effet ! Pourrais-je faire une suggestion ? serait-il possible d'avoir le même mais à la sauce VB.NET ? Je ne sais pas si toi, Cacophrene, tu maitrises suffisament le VB.NET pour nous proposer ce tuto mais ce serait bien si, dans le cas contriare, quelqu'un d'autre nous concocte cela !
    En effet, je code en VB (4, 5 et 6) depuis plus de 10 ans et donc l'optimisation en VB6, je maîtrise bien mais me voila parti dans l'aventure VB.NEt et la, c'est le désastre ! Les premiers tests de traitement que j'ai réalisé pour comparer VB6 et VB.NET sont sidérents ! Ils me pousseraient presque à ne pas passer en VB.NET mais à rester en VB6. Je suis certain que ces résultats minables pour vB.Net par rapport à VB6 sont lié au fait que je débute en VB.NET et donc que je code dans ce langage comme une grosse tanche, alors qu'en VB6, j'arrive à optimiser mes algos et mes instructions, pour gagner des centièmes à chaque fois, comme le dis Lermitte222, mais dans une boucle de traitemment faisant 500 000 de passages, ca commence à chiffrer pour l'utilisateur final.

    Donc voila, si quelqu'un maîtrise suffisament VB.NEt pour nous proposer un tuto sur le même sujet et de la même qualité que celui-ci, je suis preneur !!

    Kristof_Koder

  • signaler à un administrateur
    Commentaire de Cacophrene le 10/11/2007 07:55:42

    Salut !

    En ce qui me concerne j'ai presque abandonné VB6... mais pas pour passer à .NET, désolé.

    Cordialement,
    Cacophrène

  • signaler à un administrateur
    Commentaire de lacomm le 13/11/2007 11:13:48

    Merci,

    En effet, il y a une grosse différence entre "", qui compte pour une cellule et vbNullString, qui ne compte pas. Ca m'a permis d'éviter une tonne de prog inutile.

  • signaler à un administrateur
    Commentaire de sermonne le 31/12/2007 13:29:59

    merci
    je n'ai retenu que ceci "un bon programme est un programme bien pensé".
    c'est valable pour tout

  • signaler à un administrateur
    Commentaire de vicosta le 02/02/2008 14:09:06

    Je viens de découvrir ce tutorial et j'ai testé un peu les optimisations descrites. Grand merci à Cacophrene
    Je me permets de décrire l'un de mes testes:

    Private Sub Command1_Click()
    Dim D as String, C as String, I as Long, T as Long
    T = GetTickCount
    D = "Salut, je suis la"
    For I = 1 To 9999999
    C = Mid(D, 2, 6)
    ' C = Mid$(D, 2, 6)' ceci est 50% plus ràpide !!!
    Next
    MsgBox GetTickCount - T
    End Sub

  • signaler à un administrateur
    Commentaire de ciberrique le 02/02/2008 14:24:19

    Je me permet d'ajouter la difference entre les fonctions len et lenb. Les données ne sont pas traitées de la même façon d'ou une différence de calcul. Enfin ca reste a verifier proprement...

  • signaler à un administrateur
    Commentaire de Kristof_Koder le 04/02/2008 15:50:45

    Pour info, Len() retourne la longueur en caractères et LenB() la longueur en octets. Comme VB travaillene UNICODE, Len() dois faire une division par deux après avoir fait le même job que LenB()

Ajouter un commentaire

Pub



Appels d'offres

CalendriCode

Septembre 2008
LMMJVSD
1234567
891011121314
15161718192021
22232425262728
2930     

VS Express FR Gratuit !

VS Express en français et 100% gratuit !

Boutique

Boutique de goodies CodeS-SourceS