Discussion :

[6SiCK6]

Bonjour, je viens vers vous avec quelque questions.

Je suis en stage et pour le boulot qu'on m'a confié, j'ai besoin de lire jusqu'à 200000 fichiers d'acquisition (binaires) pouvant peser dans les 500 ko environ. J'ai fait un petit programme en console windows qui parse ce type de fichier (en C standard) afin de pouvoir les traiter un par un. Mais maintenant j'ai besoin de vos lumières pour décider quelle stratégie je dois appliquer pour lire les 200000 fichiers de manière optimale, donc voilà mes questions:

- le fait d'avoir 200000 fichiers dans le même répertoire est-il plus couteux que de mettre ces fichiers dans plusieurs répertoires?
- serait-il avantageux de concaténer ces fichiers en un plus gros fichier?

(toute autre idée sera la bienvenue ^^)

Pour effectuer ces traitements, je disposerai d'une machine sous windows (vista) équipée d'un Xeon 4 coeurs (le soft sera parallèlisé afin de tirer parti des quatre coeurs), de deux velociraptors en RAID0 et pour la ram je sais plus (je n'ai pas accès a cette machine quand je veux).

Merci d'avance à ceux qui répondront.

A bientôt.

[Mac LAK]

- le fait d'avoir 200000 fichiers dans le même répertoire est-il plus couteux que de mettre ces fichiers dans plusieurs répertoires?

Normalement, oui. La recherche dans un répertoire est un peu plus longue s'il y a beaucoup de fichiers.

- serait-il avantageux de concaténer ces fichiers en un plus gros fichier?

Oui, surtout si le fichier final est non-fragmenté.

Toutefois, concaténer "à la main" ces fichiers avant traitement risque de te faire perdre énormément de temps, au point de rendre l'opération plus coûteuse au bilan final... Il faudrait que les données soient nativement dans un seul fichier, ce qui est peu probable.
Le déplacement vers de multiples répertoires aura le même effet. Il faudrait que les données soient nativement organisées comme ça, y compris pour les futurs ajouts de fichiers binaires.

Bref, si actuellement tu as 200.000 fichiers dans un seul répertoire et que les "nouveaux" fichiers créés vont systématiquement dans ce répertoire là, faudra faire avec si ce n'est pas modifiable : toute modification "temporaire" d'organisation te fera perdre plus de temps qu'autre chose.

(toute autre idée sera la bienvenue ^^)

Cela dépend aussi de ce que tu vas faire de ces fichiers : OK, tu dis que tu as un programme pour les parser. C'est très bien, mais que produit-il comme résultat ?

De façon générale, Windows gère bien mieux les threads que les processus : il vaudrait donc mieux rendre ton programme multithread et multicoeur plutôt que de l'appeler quatre fois via un batch.

Ensuite, une piste qui pourrait être intéressante serait de dédier un coeur à lire les fichiers et alimenter les coeurs de "calcul" (trois, donc) avec les données, plutôt que de laisser les coeurs se "battre" pour l'accès au disque. Si tu dois écrire un résultat dans un fichier, alors dédier un autre coeur à cette écriture (si possible en différé, ou l'expédier par réseau ?) peut là aussi être une piste d'optimisation.

Après, sans savoir ce que tu dois réellement faire de façon concrète, difficile de t'aiguiller plus que ça...

[6SiCK6]

Ok, merci pour ta réponse rapide.

Pour ce qui est de ce programme de parsage il est en console uniquement à des vues de test, donc la version "finale" du soft sera parallèlisée à l'aide de threads et bénéficiera d'une interface graphique MFC, il ne sera pas question de scripts batch.

Ensuite lors de la lecture des fichiers, je stocke les infos des fichiers dans une structure. Et c'est sur cette structure que seront faits les plus gros calculs.

Pour finir, l'organisation des fichiers d'acquisition ne pose pas de problème, mon maitre de stage fera en sorte que lors de l'acquisition, ces fichiers soient concaténés, ou bien stockés dans des dossiers différents ou toute autre bidouille. En tout cas mon soft n'interviendra que lorsque tous les fichiers d'acquisition auront été écrits sur le disque.

Ce qu'il faut avoir à l'esprit c'est la performance ^^.

[Mac LAK]

Heu, j'avais pas fait le calcul... Au total, ça fait 96 gigas de données environ, ton truc... Tout charger en RAM ?? Utopique !

Si l'organisation est "libre", alors un seul répertoire contenant un certain nombre de fichiers concaténés (disons que le nombre de fichiers unitaires concaténés doit correspondre à une unité de calcul significative) me semble la meilleure solution... Fichiers de 500 Mo maximum, soit l'équivalent de 1000 fichiers unitaires, pour un total de 200 "gros" fichiers au maximum dans le répertoire général. Je pense que là, à la louche du moins, tu arrivera à quelque chose de proche de l'optimal (les très très gros fichiers peuvent devenir lents à gérer parfois).

De plus, cela permet de charger intégralement en RAM un de ces fichiers concaténé (500 Mo, c'est gérable par la plupart des PC quand même), et donc de travailler à peu près sereinement. Si tu as assez de RAM, tu peux tenter aussi de commencer à précharger (en priorité basse) le prochain fichier pendant le traitement du précédent.

[6SiCK6]

Heu, j'avais pas fait le calcul... Au total, ça fait 96 gigas de données environ, ton truc... Tout charger en RAM ?? Utopique !

Je ne voulais pas créer un seul fichier avec tous les fichiers d'acquisition, je me disais bien que j'allais faire crasher la ram ^^

En tout cas merci pour ta réponse, je vais en discuter avec mon maître de stage pour voir ce qu'il est possible de faire.

[Mac LAK]

Je ne voulais pas créer un seul fichier avec tous les fichiers d'acquisition, je me disais bien que j'allais faire crasher la ram ^^

Ça me rassure...

En tout cas merci pour ta réponse, je vais en discuter avec mon maître de stage pour voir ce qu'il est possible de faire.

De rien. Un seul répertoire avec 200 "gros" fichiers de maximum 500 Mo (ou 1000 données unitaires, en fonction du premier atteint) me semble tout à fait raisonnable pour ma part.