Discussion :

[Hartok]

Bonjour,

Dans le programme sur lequel je suis en train de bosser, à un moment, je dois vérifier si des fichiers sont présents sur le DD avant de continuer.

A priori, rien de compliqué :

if ((FindFirst(m_Chemin+'*.jpg', $3F,s)=0) then ...

Mon problème est qu'à froid, cette petite recherche est très lente (~1sec), ce qui est handicapant pour les performances globales (des appels similaires sont réalisés à plusieurs reprises). Les dossiers en question peuvent contenir plusieurs milliers de fichiers, c'est sûrement lié à ça. De plus, ce n'est lent que pour la première utilisation du logiciel, s'il est relancé une seconde fois sans reboot, l'action est quasi-immédiate. J'ai également testé de visiter les dossiers en question avant le lancement du programme, et là aussi ça a été très rapide. Windows (XP) est donc montré du doigt d'après moi.

Je souhaiterais donc savoir si vous connaissiez des solutions alternatives qui puissent me faire gagner en vitesse. Je peux à la limite lancer un script pour "visiter" ces répertoires en background en prévision des FindFirst.

Merci !

[ShaiLeTroll]

Regarde le Clic Droit (Menu Contextuel) Propriétés d'un Dossier, tu vois le temps que met l'Explorateur à calculer, ben, FindFirst mets le même temps, j'ai utilisé FindFirst sur des Dossiers de plusieurs Go, contenant des milliers de fichiers tif, je te confirme, cela prend du temps, idem, on utilise un système de numérotation et de découpage de dossier pour que l'on est au plus 1000 sous-dossiers dans un dossier (et cela sur 3 niveaux)

Tu peux lancer ce calcul dans un Thread dès que tu sais qu'il finira par arriver !

[Hartok]

Merci.

Dans un soucis de compatibilité, je ne peux remettre en cause l'organisation des fichiers. Je me lance du coup dans une sorte de prefetch dans un thread temporaire. Reste à trouver le bon moment pour l'exécuter, mais j'ai ma petite idée.

[Dr.Who]

~1sec pour quelques milliers de fichiers ... ce n'est pas lent.

faut arrêter un peu de croire que tout peux être fait en moins de 10milli-secondes surtout quand on tente d'accéder à un support physique et mécanique (disque dur, CD/DVD, disquette, cassette à bande).

Tout dépend de la rapidité de l'accès disque. un disque UDMA affichera un temps plus long qu'un SATA plus long qu'un SATA 2 plus long qu'un SCSI en RAID plus long qu'un disque RAM.

à l'époque des support sur bande (comme dans DARYL ou War Games) il fallait plusieurs minutes pour lire un fichier de quelques octets, plusieurs heures pour copier ou effacer les données, ou simplement aller lire le tout dernier fichier de la bande.

donc ne nous plaignons pas pour quelques millisecondes à patienter.

aprés tu peux effectivement lire avec un thread au coups par coups mais ce sera plus long.
autant tout lire d'un coups dans un thread et une fois les données en cache tu y accedera plus vite comme tu l'as constaté.

aprés il faut optimiser le code allentours pour gagner en vitesse de traitement.

[Hartok]

Je reconnais que ~1sec pour des milliers de fichiers ce n'est pas très long.
Mais avoir des freezes de plusieurs dizaines de secondes ce n'est pas génial au niveau de l'expérience de l'utilisateur final (qui ne se doute pas des causes de ce ralentissement).

Le Thread marche pas mal. Le temps gagné dépend du temps que l'utilisateur perd en se baladant dans les menus, mais c'est déjà ça de gagné.

[Nebulix]

Je reconnais que ~1sec pour des milliers de fichiers ce n'est pas très long.
Mais avoir des freezes de plusieurs dizaines de secondes ce n'est pas génial au niveau de l'expérience de l'utilisateur final (qui ne se doute pas des causes de ce ralentissement).

Le Thread marche pas mal. Le temps gagné dépend du temps que l'utilisateur perd en se baladant dans les menus, mais c'est déjà ça de gagné.

Parce que tu le laisses s'ennuyer. Affiche une belle barre de progression et il sera convaincu que l'ordinateur fait plein de choses super compliquées et il sera rempli d'admiration pour le programmeur

[Hartok]

Le problème est qu'ils possèdent également une ancienne version moins complexe mais beaucoup plus rapide... Je peux même pas bluffer. ^^

J'ai viré pas mal de contrôles, la performance semble le critère déterminant...

[ShaiLeTroll]

Parce que tu le laisses s'ennuyer. Affiche une belle barre de progression et il sera convaincu que l'ordinateur fait plein de choses

ça c'est très pertinent, j'avais un chargement de fenêtre assez long (XML transformé en DFM par XSL, bcp d'onglet, bien un millier de composant parfois, des changements de Owner et tout et tout), et bien entre chaque étape, j'ai mis une progression, même moi, j'ai l'impression que cela va plus vite qu'avant (ce qui est faux, c'est plus lent avec l'affichage) mais l'ordi n'est pas bloqué, il nous parle, ça nous rassure tous !

[Hartok]

Sinon, il y a les super barres de progression, avec l'effet de vague. Même immobile, la vague donne l'illusion que ça avance !

[Nebulix]

... une ancienne version moins complexe mais beaucoup plus rapide...

(soupir)

[Paul TOTH]

Merci.

Dans un soucis de compatibilité, je ne peux remettre en cause l'organisation des fichiers. Je me lance du coup dans une sorte de prefetch dans un thread temporaire. Reste à trouver le bon moment pour l'exécuter, mais j'ai ma petite idée.

d'où viennent les images ? ne peux-tu avoir un fichier texte qui contient la liste des fichiers ?

[Hartok]

Merci pour vos messages, mais c'est Résolu. ^^

Je peux avoir un fichier texte, mais l'intérêt ici était de contrôler si tout était bien présent connaissant les emplacements théoriques. J'ai remplacé ce contrôle par un autre moins gourmand.