Parcours très rapide d'une arborescence ?

Bonjour,

J'ai écrit un programme qui parcourt et compare les fichiers de deux arborescences.

J'ai fait mon parcours avec les fonctions classiques FindFirst et FindNext de la VCL.

Au premier parcours, j'obtiens un temps de 10 secondes par exemple (pour un arbre de 100 Mo de données) et les fois suivantes le parcours du même arbre prend 3 secondes à peu près ? Pourquoi cette différence alors que ni les fichiers ni le programme n'a changé ? Windows fait des optimisations à l'insu de mon plein gré ? :)

J'ai essayé quelques programmes de synchronsation de fichiers et la comparaison de mes deux arbres de 100 Mo prends moins de 1 seconde !!

Il y a une méthode plus rapide que FindFirst et FindNext ?
Si on passe par l'API Windows (IShellFolder) le parcours est plus rapide ?

Je serais curieux de connaitre votre avis si vous avez testé les performances des parcours de fichiers sous Windows...

... ou si vous avez d'autres idées, ou si vous avez des liens (même en anglais) sur la gestion performante des fichiers sous Windows...

Merci.

j'avoue que je suis un peu dans la même situation. Je cherche aussi à faire des répliques de mon PC vers des serveurs. Malheureusement, je n'ai pas la solution, mais j'ai une piste. Au lieu de parcourir les fichiers par un findfirst, il faudrait parcourir la table d'allocation du disque dur. Apparement c'est super rapide. Un pote à moi l'a fait en Pascal, je vais essayer de récupérer la source. Par contre, est ce que çà marche si on doit repliquer sur des serveur distants ? je ne pense pas !

PS: si tu as d'autres pistes, n'hésite pas à me les donner stp.

Citation:

---

Pourquoi cette différence alors que ni les fichiers ni le programme n'a changé ? Windows fait des optimisations à l'insu de mon plein gré ?

---

j'ai fait les même constatations. je pense que windows mais les données en cache ce qui explique que la deuxième fois c'est plus rapide. Et puis, la mémoire cache d'un disque dur, ça sert à ça aussi !

mais je sais pas comment on peut faire pour avoir les même temps de réponse que les autres prog ou même que l'explorer tout simplement !

En passant par ShellFolder je pense que ce sera bcp plus lent ;
Peut-être qu'en passant par les API natives de Windows et non de la VCL comme FindFirstFile c'est + rapide

aurais tu un exemple sous le coude ?

Bonsoir,

Merci pour ces réponses !

Effectivement, je pense qu'il faut faire plusieurs essais :
- je peux améliorer un peu mon algo
- je vais effectivement essayer FindFirstFile et FindNextFile
- je vais essayer GetFileInformationByHandle pour récupérer directement
la date de modification et la taille des fichiers à comparer en une seule fois au lieu d'utiliser GetFileAge + une fonction pour la taille...
- il y a aussi _findfirsti64 and _findnexti64 à tester
- je vais peut-être aussi utiliser IShellFolder quand même. Dans les dossiers Windows 32, il y a une option "Autoriser l'indexation de ce fichier pour les recherches rapides". Peut-être que IShellFolder utilise cette option ?

A tester.
Ca tombe bien, voila un long week-end qui arrive ! ;-)

Merci encore,
A+

Bonjour,

J'ai fait quelques essais ce matin.

J'ai commencé par refaire des mesures avec l'ancienne version de mon prog sur mes données (118 Mo; 48 répertoires; 384 fichiers)

Temps :
1er essai : 27 s.
2ème essai : 5 s.
3ème et nièmes : 3s. 700ms environ

J'ai amélioré un peu mon algo de comparaison avec un seul appel à GetFileAttributesEx au lieu de FileExists, FileAge, fonction de calul des longueurs avec fopen-fseek.
Voici les résultats :

1er : 1s 625ms
2eme et suivants : 0s 800ms

Je n'ai pas encore utilisé FindFirstFile et FindNextFile, et je peux encore améliorer mon algo.

J'avais codé ça comme un sagouin quoi, avec des redondances de partout... :oops:

Je n'irais pas jusqu'à coder en assembleur, mais ça vaut le coup d'optimiser son code et de travailler avec les API Windows au lieu de la VCL !! :-))

L'usage de FindFirstFile et FindNextFile, FindClose de l'API Windows n'apporte aucun gain de vitesse (décelable en millisecondes) par rapport à FindFirst et FindNext de la VCL...