je vois pas ce que je peu ajouter de plus a l'explication de Cirec... si ce n'est que,
quand tu fait une fonction de convertion de ce genre, chiffre vers lettres, lettres vers chiffre, process d'image etc. il faut que ce sois trés rapide.
par contre on considere que les methodes de compression, cryptage, ou lourd traitement video ou 2d/3d peuvent etre lente (cela depend des cas) et donc afficher un etat de progression.
bien sur, une methode qui donne le meme resultat mais plus rapidement sera toujours bienvenue.
moi, je considere que des methodes legere doivent tourner en dessous de 1000ms pour 1MCall, surtout les methodes succeptibles d'etres appélée 10 ou 20 fois ou plus dans une boucle ou une methode.
et encore la on as 125ms sur une config recente qui est prevue pour de la DAO 2d/3d, de la MAO et faire tourner des jeux recents.
alors je te laisse imaginer l'importance de l'optimisation sur des config plus modestes... une methode qui mets presque 10 secondes pour 1 millions d'appels pour ce genre de truc c'est trop :)
meme si ça parrait un peu deroutant de tester 1 millions d'appels, c'est ce qu'on appel un test de charge, ça permet egalement de tester la stabilitée de la methode pour detecter d'eventuel probleme de pointeur ou de fuite memoire ou de debordement.
un peu comme quand on test la charge d'un serveur pour voir si tout vas bien et pour regler les limites.
pour tester c'est simple, voici un petit shema que j'utilise souvent :
procedure TForm1.Button1Click(sender : TObject);
var GT1,GT2, N : cardinal;
begin
GT1 := GetTickCount;
for N := 1 to 1000000 do Methode1; { supposée la plus lente }
GT1 := GetTickCount-GT1;
GT2 := GetTickCount;
for N := 1 to 1000000 do Methode2; { supposée la plus rapide }
GT2 := GetTickCount-GT2;
Label1.caption := format('%d ms VS %d ms [%.2f%%]',
[GT1, GT2, Abs( (100/GT1)*(GT1-GT2) )]);
end;
certe GetTickCount n'est pas le meilleur de la precision, mais quand on as un ecart de 9500 a 125 ... on se rend vite compte
de qui est la plus rapide...
Croc (click me)