Discussion :

[Yurck]

Bonjour,

J'ai un programme de traitement de fichier avec une barre de progresion de la 1ère à la dernière ligne.

Dernièrement on m'a demandé de traiter le fichier dans un ordre spécifique. J'ai donc tous simplement utiliser la méthode de tri proposer par le TStringList.

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
19
20
21
22
23
 
function TriFichier(List: TStringList; Index1, Index2: Integer): Integer;
Var
  S1, S2: string;
begin 
  // gestion spécifique de clef
  S1 := LectureClef(List[Index1]); 
  S2 := LectureClef(List[Index2]); 
 
  if S1 > S2 then
    Result := 1
  else
    if S1 < S2 then
      Result := -1
    else
      Result := 0;
end;
 
procedure TForm1.TrieFichier(FichierATrier : TStringList);
begin
  if ClefDeTri>'' then
    FichierATrier.CustomSort(TriFichier);
end;

Mon problème c'est que le tri du fichier prends 90 % (estimation à la louche) du temps de traitement.
Ma barre de progression devient donc "ridicule" comme dirait l'autre.

Comment suivre la progression d'un tel système de tri ?

Je fais donc appel à votre sagacité et votre expérience pour me proposer une solution intelligente.

a+

[TicTacToe]

Salut,

Il faudrait mettre un compteur d'appel CPT dans la fonction CallBack de comparaison.
LE problème, c'est que l'on connait pas à l'avance, combien de fois le tri Quicksort de Delphi va faire appel à cette fonction de callBack.

Si on part du principe que l'on connait ce nombre TOT, le %age d'avancement est trivial.

Maintenant, puisqu'il s'agit d'un tri Quicksort il me semble, il faudrait peut etre faire un tour du coté du forum Algorithme, pour demander un nombre "moyen" d'appel de la fonction de comparaison en fonction du nombre d'éléments de départ.
Peut-être que tu pourras avoir une jauge "a peu près" réaliste avec ces données.

De plus, si ta liste est partiellement triées ou totalement dans le désordre, tu peux peut être affiner ce nombre TOT en fonction de tes propres données (un peu +, un peu -...?)

bon courage !

[PadawanDuDelphi]

Salut,

Le problème en réalité c'est que tu as aucun moyen de savoir, à priori le temps que va prendre ton tri. Tout ce que tu peut faire c'est une estimation du temps que ça va prendre. Quick sort a une complexité algorithmique en O(n ln(n)), mais pour plus de détail, regarde ce lien ou sur le forum algo.

http://fr.wikipedia.org/wiki/Tri_rapide

Sinon, c'est peut-être une idée stupide, mais tu ne pourrais pas faire une barre ""infini", comme celle qui se lance avec la commande rechercher sous Windows ?

@+.

[Droïde Système7]

Bonjour,

Sans oublier les doubles barres à la mode version K2000, de cette façon ce n'est pas en rapport avec le temps de traitement, mais au moins ça matérialise le temps d'attente

Pas trop une solution pour puriste, simplement une roue de secours, somme toute assez élégante s'il n'est pas possible de calculer avec précision les 100%.

[Yurck]

Bien,
Vous ne faites qu'apporter de l'eau à mon moulin


a+

[TicTacToe]

J'ai jamais essayé, mais ce serait interessant de voir si calculer un nombre 'fictif' de tour dans la fonction callback.

Code :

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

1
2
3
TOT1 := NbElts * ln( NbElts );
TOT2 := NbElts * NbElts;
TOT := ( TOT1 + TOT2 ) / 2; // au pif la moyenne entre les complexité moyenne et maxi)

et

D'incrémenter la valeur CPT dans la fonction de callback.

et de voir ou se situe CPT par rapport à TOT au fur et à mesure du tri selon plusieurs tris différents.

C'est à tenter ^^

PS: Sauf que je sais pas si la complexité correspond à UN seul appel à la fonction de comparaison !

[Droïde Système7]

Ou bien de prendre le problème par un autre bout :

Est-il possible de vers la fin de cette procédure de tri, de connaître exactement à un moment ce reste à taiter ?

Si oui, il suffirait alors déjà dans un premier temps de lancer doucement la barre de progression, et à un certain moment de mettre en synchro le reste de la barre sur le reste du tri...

Autrement dit : possible ou pas de connaître à un certain moment, le reste précis à gérer ?

[Yurck]

Mouaip,

Le tri de mon fichier de 5Mo mettant près de deux heures, je pense qu'il va falloir que je fasse quelque chose
de plus sioux que le "Veuillez patienter SVP !".

J'ai à l'heure d'aujourd'hui d'autres priorités plus prioritaires, de l'ordre du bug convulsif de fin de semaine, mais en fin de semaine prochaine je vais m'atteler à la recherche d'une solution satisfaisante.

Merci à suivre...

[Yurck]

possible ou pas de connaître à un certain moment, le reste précis à gérer ?

Ton idée J-P comme celle de TicTacToe est intéressante.

En fait pour un tel temps de traitement la précision n'est pas mon souci principal.
Mais si je pouvais signifier à ce cher utilisateur qu'il peut aller manger tranquillement et qu'il n'est pas nécessaire de m'appeler tous les 1/4 d'heure pour savoir si il ne faut pas rebooter le système central à impulsion atomique.
Peut-être qu'en mesurant et en enregistrant tous simplement le temps proportionel à la taille des fichiers proposés je serai en mesure d'affiner au fil du temps mon estimation.

Demain sera un autre jour. Bien malin qui sait attendre à demain.

Merci encore.

[TicTacToe]

bah ca me démangeais alors j'ai essayé et prévoir un total de

TOT = NbElts * ln( NbElts ) * Coef

avec coef variant de 1.5 a 2 selon l'optimisme du moment...
pour un tri sur 20000 chaines au hasard

et ca marche plutot bien au niveau de la jauge, qui est régulière dans son avancement, et qui va au bout + ou - delta....

sinon une autre solution, tu optimises ton code pour qu'il ne dure plus 1/4 d'heure mais 10 sec

[Graffito]

Bonjour,

Le tri de mon fichier de 5Mo mettant près de deux heures,

Le temps me semble tout à fait excessif, si par exemple les 5Mo correspondent à 50 000 enregistrements de 100 octets.

• Que fait la donc la fonction de comparaison pour être aussi gourmande?
• Les données sont-elles toutes en mémoire ?

[Yurck]

Excessif c'est peu dire mais on ne fait d'omelette sans ...

Oui les données sont toutes en mémoire il s'agit d'un TStringList.
De plus la fonction LectureClef est sans doute à améliorer car suivant un système de paramétrage spécifique elle concaténe des parties, retrouvées grace à un caractère spécial, de la chaine de base dans un ordre tout aussi spécifique.
Sachant que
- dans cette chaine j'ai des dates à la francaise et que pour trié il faut bien sûr retourner le tout à chaque fois.
- Qu'il faut mettre les champs chaine en majuscule en otant les caractères spéciaux.
- etc...

Enfin trève d'excuses c'est surement améliorable.

Merci à J-P je mettrais en place sa solution qui semble s'approcher de l'à peu près que je recherche.

a+

[Graffito]

Bonjour,

Je te propose une solution qu'on adopte souvent dans ces cas là :

Code :

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

1
2
3
4
5
6
7
8
9
// insertion d'une clef de longeur fixe devant chaque élément de la stringlist
For i:=1 to mystringlist.count-1 do 
     myTstringlist[i]:=LectureClef(myTstringlist[i])+myTstringlist[i]) ;
// tri
mytstringlist.sort;
// // suppression des clefs précédant chaque élément de la stringlist
For i:=1 to mystringlist.count-1 do 
    myTstringlist[i]:=copy(myTstringlist[i],longueur_cle+1, 
             length(myTstringlist[i])-longueurcle) ;

La fonction LectureClef devra simplement concaténer chaines de caractéres "paddés" par des blancs à droite sur des longueur fixes et entiers exprimés en chaine de caractère et "paddés" à gauche par des zéros.