Discussion :

[Jipété]

Bonsoir,

le titre n'est pas top mais je ne sais pas trop comment le dire autrement.

Tout le monde sait que dans une boucle il faut rendre la main au système sinon on se retrouve avec un prog qui a l'air planté, et on rajoute donc Application.ProcessMessages; dans le corps de la boucle.
Et comme c'est time consuming il parait, on l'applique de temps en temps, genre

Code :

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

1
2
3
4
for i := 0 to grand_nombre-1 do begin
  taf_avec(i);
  if (i mod 10 = 0) then Application.ProcessMessages;
end;

J'ai un dossier qui contient 4 sous-dossiers, chacun contenant des fichiers en nombre et taille variables.
Il y en a beaucoup alors je veux les trier en sous-sous-dossiers, genre tous les 50 fichiers je crée un dossier et j'y déplace les 50 fichiers, et ça, tant qu'il y a des fichiers.

Avant de lancer ça dans la vraie vie (environ 600 000 fichiers, rien que ça !), j'ai monté un dossier de simulation qui contient 4 sous-dossiers avec respectivement 10, 5, 1 et 0 fichiers, et je définis maxfiles à 3.
Je m'attends donc après l'exécution à avoir 4 sous-sous-dossiers dans le premier sous-dossier avec 3, 3, 3, 1 fichiers,
à avoir 2 s-s-d dans le deuxième avec 3 et 2 fics, 1 s-s-d dans le troisième avec 1 fic et rien dans le quatrième.

On est d'accord jusque là ?
Je pose la question ici parce que c'est juste après qu'on rigole et que ça devient tendu…

D'abord j'ai estimé que, dans chaque sous-dossier, le dernier s-s-d n'aurait pas besoin d'Application.ProcessMessages; dans sa boucle de remplissage, puisque c'est la dernière étape et que le nombre de fichiers sera toujours inférieur à 50 (3 en test), et j'ai donc positionné cette respiration à la fin de la boucle gérant l'autre cas, quand il faut travailler avec des boucles de 50 (3 en test), qui commencent par la création d'un nouveau dossier pour les accueillir.

C'est clair ?
Parce que quand j'exécute sur mes 16 fichiers de test, le résultat est complètement en vrac (sauf pour le dossier vide, qui reste toujours vide).
Oui oui, vous avez bien lu, par exemple j'ai relevé ce soir ça comme résultat :
dans le 1^er s-d (10 fichiers au départ), 2 s-s-d (au lieu de 4), le 1er contenant 5 fichiers, le 2e contenant les 2 autres s-s-d et 1 fic.
dans le 2^e s-d, 1 seul s-s-d (au lieu de 2) qui contient ses 3 fichiers prévus et l'autre s-s-d avec 2 fichiers.
le 3^e s-d est correct avec 1 s-s-d contenant 1 fichier, comme prévu.
et le 4^e ne contient rien, puisqu'il ne contenait rien au départ.

J'essaye un croquis

Code :

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

1
2
3
4
5
6
7
8
9
10
   au départ    |   attendu  |  trouvé
----------------|------------|------------
sd1 10 fichiers | ssd1 3 fic | ssd1 5 fic
                | ssd2 3 fic | ssd2 1 fic + ssd3 3 fic + ssd4 1 fic
                | ssd3 3 fic | 
                | ssd4 1 fic |
sd2  5 fichiers | ssd1 3 fic | ssd1 3 fic + ssd2 2 fic
                | ssd2 2 fic |
sd3  1 fichier  | ssd1 1 fic | ssd1 1 fic 
sd4  vide       | rien       | rien

Bon bref, c'est une pagaille immonde et impossible à mettre en prod'…

Et pourtant l'algo est correct.
Oui oui, je vous entends hurler "mais kess t'en sais ? C'est toi qui t'es fichu dedans, etc."
Ben non.
Parce qu'il suffit que je rajoute des lignes de log plein les boucles pour que miraculeusement, ça tombe en marche correcte.
Les lignes de log consistent à ajouter à un TMemo une ligne contenant le nom du fichier qui va être déplacé, avec un suivi de compteur, le tout suivi d'un Application.ProcessMessages; bien sûr.

Le problème, c'est que sur 16 fichiers je n'ai pas le temps de voir l'impact de ces respirations sur la durée d'exécution, mais si, au lieu d'une respiration tous les 50 fichiers soit 12000 pour la globalité des fichiers, la chose passe 600 000 respirations, combien de temps ça dure, une respiration ?

Allez, tiens, le code (les appels genre MakeFolder ont des noms suffisament sympas pour que je me dispense de les joindre, ça allège) :

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
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
procedure TForm1.WorkOnDossier(chemin: string; count: integer);
var
  d,i: integer;
  maxfiles: integer;
  racine: string;
  src,dst: string;
begin
  maxfiles := 3;               
  racine := copy(chemin, Length(chemin)-2, 3)+'_';
  d := 0;
  while count > maxfiles do begin
    inc(d);
    dst := chemin+'/'+racine+IntToStr(d);
    MakeFolder(dst);
    //log(dst + ' -a '+IntToStr(d));
    for i := 0 to maxfiles-1 do begin
      src := chemin+'/'+laliste[(maxfiles*(d-1))+i];
      MoveFilesFromTo(src, dst);
      //log(src + '  -a'+' -c'+IntToStr(count));
    end;
    dec(count, maxfiles);
    // tous les maxfiles, respirer un coup :
    log(chemin + ' ' +racine+IntToStr(d))
  end;
  // fichiers restants
  if count > 0 then begin
    inc(d);
    dst := chemin+'/'+racine+IntToStr(d);
    MakeFolder(dst);
    //log(dst + ' -b '+IntToStr(d));
    while count > 0 do begin
      for i := 0 to count-1 do begin
        src := chemin+'/'+laliste[(maxfiles*(d-1))+i];
        MoveFilesFromTo(src, dst);
        //log(src + '  -b'+' -c'+IntToStr(count));
        dec(count);
      end;
    end;
  end;
end;

Vous voyez les lignes de log commentées (sauf la respiration principale) donc génératrices de résultats en vrac, il suffit de décommenter les 4 lignes pour que ça soit bon.

Une idée pour que ça soit bon sans passer 3 jours à l'exécution (ou plus, peut-être) ?
Merci d'avoir lu tout ça.

[Roland Chastain]

Pas sûr d'avoir tout compris mais une ou deux choses me viennent à l'esprit. Personnellement, au lieu d'utiliser ProcessMessages, je créerais un sous-processus indépendant (thread) qui se chargerait de faire le travail, et dans la procédure je mettrais des Sleep(1) aux bons endroits, pour éviter d'éventuels chevauchements.

Une autre idée qui me vient, c'est que si tu déplaces des fichiers, la liste des fichiers qui est en mémoire dans le programme n'est plus bonne. Est-ce qu'il ne faudrait pas, après chaque déplacement, rafraîchir la liste ?

Réponse écrite par quelqu'un qui aurait peut-être bien fait d'aller dormir.

[Jipété]

Pas sûr d'avoir tout compris

Je résume : si pas de respiration (ou pas assez longue) dans la boucle de création des dossiers et de déplacement des fichiers, le résultat est en vrac.

Personnellement, au lieu d'utiliser ProcessMessages, je créerais un sous-processus indépendant (thread) qui se chargerait de faire le travail, et dans la procédure je mettrais des Sleep(1) aux bons endroits, pour éviter d'éventuels chevauchements.

Y a des jours je me dis que ces machins sympathiques avec des noms facilement mémorisables (ProcessMessages) ne sont que des manières agréables de nous cacher des choses compliquées mais, in fine, c'est pareil.
Réfléchis : le problème est dans la trop grande rapidité d'exécution de la boucle alors, qu'elle soit dans le thread principal ou dans un secondaire, quelle différence ?

Une autre idée qui me vient, c'est que si tu déplaces des fichiers, la liste des fichiers qui est en mémoire dans le programme n'est plus bonne. Est-ce qu'il ne faudrait pas, après chaque déplacement, rafraîchir la liste ?

J'en suis bien conscient, et c'est d'ailleurs pour ça que je parcours la liste du début (0) à la fin (laliste.count-1) en utilisant une astuce : puisqu'il y a 50 fichiers par sous-dossier et que j'utilise une variable d pour numéroter et nommer ces sous-dossiers, je l'utilise encore un coup : laliste[(maxfiles*(d-1))+i] et ça fonctionne, car quand il y a suffisamment de respiration le résultat est correct.
d- parce que je commence avec d := 0 et que je l'incrémente pour créer le dossier 1. Tiens, ça me fait penser : je vais modifier ça en commençant avec d à 1 et l'incrémenter après, ça fera une opération de moins à chaque tour de boucle, c'est toujours ça de gagné.

Moi aussi j'ai eu une idée (la nuit porte conseil et c'est peut-être ça qui m'a tiré du lit) : maintenant que mon algo est au point, j'abandonne Laz pour le porter vers un script Bash natif Linux, ça devrait le faire tip-top. Après tout, pour ce taf je n'ai pas besoin d'ihm.

Réponse écrite par quelqu'un qui aurait peut-être bien fait d'aller dormir.

C'est vrai que tu t'es couché à pas d'heure ! Bah, d'un autre côté, je me suis levé avec les poules.
Je regarde ce problème d'échecs dès que le rangement des 600 000 fichiers est lancé

[Jipété]

[...] maintenant que mon algo est au point, j'abandonne Laz pour le porter vers un script Bash natif Linux, ça devrait le faire tip-top. Après tout, pour ce taf je n'ai pas besoin d'ihm.

Bon sang de bois !, en 22 minutes le tri des presque 600 000 fichiers s'est effectué sans l'ombre d'un souci, et je me retrouve donc à la tête de presque 12 000 dossiers de 50 fichiers à examiner mais, tranquille, à raison de 100 dossiers (qq secondes le dossier) par jour y en a juste pour 4 mois. C'est gérable.

Linux en console pure et dure, c'est quelque chose, hein !
Donc mon algo est bon, donc il y a bien des soucis de respiration dans les boucles en mode ihm graphique, et je ne peux pas cocher car pour moi, contourner un problème ne résout pas le souci de départ, mais en tout cas c'est terminé pour cette affaire.

[Roland Chastain]

Linux en console pure et dure, c'est quelque chose, hein !

Pareil pour Windows. Il y a des tas de choses que je fais par ligne de commande. Ça va généralement beaucoup plus vite. Le point faible c'est la gestion des erreurs (peut-être parce que je ne sais pas le faire).

[anapurna]

salut

tu fait quoi dans MoveFilesFromTo ?
met avis qu'il ne flush pas entièrement la copy et donc s'en mêle les pinceaux ?

pour les batch pour gerer les erreur utilise le pipe tu n'as pas d'autre choix

voir ici pour plus d'info

[Jipété]

tu fais quoi dans MoveFilesFromTo ?

Rien de spécial : comme le nom de l'appel le laissait deviner, MoveFilesFromTo(src, dst);, c'est un simple move source destination et c'est très exactement la commande que j'ai utilisée dans le script en Bash : mv "$src" "$dst/".
C'est cette petite ligne qui a déplacé presque 600 000 fichiers en environ 22 minutes et… 0 erreur.

m'est avis qu'il ne flushe pas entièrement la copy et donc s'emmêle les pinceaux ?

Et un truc qui s'emmêle les pinceaux je jette. Parce qu'à le laisser tranquillement respirer à chaque tour de boucle, je suis sûr qu'il n'aurait pas encore fini…

[anapurna]

salut

tu veut dire un movefile ?
parce qu’un move c'est plutôt pour la mémoire

[Jipété]

tu veut dire un movefile ?
parce qu’un move c'est plutôt pour la mémoire

Pas sous Linux :

[anapurna]

Salut

Là tu me parles de batch, moi je te parle en programmation.
Le batch c'est des commandes, elles pourraient s'appeler tartenpion que cela ne changerait pas ^^

Non quand tu utilises les ProcessMessage et autres joyeusetés tu utilises le code Pascal, sinon tu peux utiliser les fonctions du shell Windows, par exemple moveFolder

[Jipété]

sinon tu peut utiliser les fonction du shell windows par exemple moveFolder

Pas sous Linux

Windows je ne connais plus (sauf une petite machine virtuelle XP pour deux-trois vieux trucs).

En plus tu parles de moveFolder qui n'a rien à faire ici, il était surtout question de MoveFiles de là où ils sont vers des nouveaux folders prêts à les accueillir sauf que c'est cette création qui est partie en sucette.

[anapurna]

salut

as tu essayé la fonction rename ou renameFile ?
si c'est sur le même disque je crois me souvenir que cela est plus rapide que movefile
après pour linux je ne sais pas comment cela est gérer