Discussion :

[philippe V]

une simple question

Je doit traiter de l'information qui est storer a l'interieur de 2000 a 4000 fichier d'ont la taille varie de 100Ko a 2Go dans mon cas chaque fichiers sera considerer comme un object. Presentement le temps de pris pour executer le travaille est en moyenne 2 heurs mais peut ateindre 6 heurs dans las cas les plus extremes, j'aimerais ameliorer le temps de traitement

pour ce qui est de la construction des object :

bienque ce ne sois pas la la principal action qui qui affecte le temps d'excution est-ce que de cree plusieur thread pour lire les fichier pourait ameliorer les performances

Merci

[Higestromm]

Selon moi je dirais non ... voir meme cela ralentirais ton programme car chaque processus liraient des données éparpillés sur le disque dur au lieu de lire les données d'une manière "relativement" linéaire... A moin que tu fasse 2 thread qui lisent chacune sur un disque dur différent...

[Aurelien.Regat-Barrel]

Je verais plutot un thread qui lis les données et un autre qui les traite. Comment procèdes-tu pour lire les fichiers ? Tes traitements sont couteux ?

[SuperCed]

Tu vas accélérer les perfs en passant en multithread si ta machine possède plusieurs processeurs.

Le plus important pour toi, sera je pense, la lecture de tes fichiers. Les accès disques sont des facteurs de vitesse très limitant.

Il est souvent conseillé de lire tes fichiers textes par (gros) blocks et non pas caractère par caractère. Ainsi, le cache du disque peut fonctionner de manière optimale.

[tut]

j'appuis la réponse d'Aurélien : un thread lecteur qui peut se permettre d'être bloqué pendant les latences de lecture sur disque dur; et un thread qui travaille les données déja lu.
Et une structure de donnée globale au milieu.
C'est un cas typique du pattern lecteur-écrivain, me semble-t-il.
En tout cas le sujet est interressant.

[Gandalf]

Pour améliorer les perfs :

separer (en termes de thread) lecture/traitement/ecriture.
ensuite si la machine est multiproc separer le traitement en threads.

Eventuellement (surtout si les fichiers ne sont pas sur le meme (controlleur IDE de) disque faire des threads differents pour les differents fichiers ->

l'idée est davoir un algo producteur consomateur

les threads lecteurs de fichier lisent pour remplir un tampon (grand de préférence) et posent quand le tampon est plein...

les threads de traitement vident le tampon et envoient leur resultat dans un nouveau tampon et posent soit quand le tampon de sortie est plein soit quand le tampon d'entrée est vide

les threads d'ecriture ecrivent sur fichier les contenu de leur tampon et posent quand il est vide...

Si le traitement est vraiement consomateur de temps il n'est pas ralenti par les operations de lecture-ecriture

Si le traitement n'est pas le facteur limitant tu ne gagneras pas grand-chose...

[tut]

Avant toute chose, il faut étudier le phénomène et comprendre ce qui est long, pour pouvoir cibler au mieux l'optimisation.
Si tu passes ton temps à optimiser un truc qui ne fait pas perdre de temps, ça ne sert à rien.

[Aurelien.Regat-Barrel]

+1
D'abord identifier ce qui est lent : lecture et/ou traitements.

[philippe V]

J'ai boucoup de travailles a faire pour tenter d'optimiser cette app.
La principale cause de la lanteur est directement a la quantiter fenomenal de donnees a traiter, l'optimisation des boucles dans le traitement feras probablement la plus grande difference au niveau du temps d'execution.
De plus certain section son ecrit en perl <<Ya probablement quelque nanoseconde a recuperer de ce coter>>

nez en moin la 1erre tache que l'app effectue est de construire ces object a partide de fichier je veux m'assure de ne pas perdre de temp d'execution pour ces operation

Merci

[Aurelien.Regat-Barrel]

Il faut détecter les goulots d'étranglement dans ton programme afin de trouver ce qu'il faut optimiser. Sinon tu vas perdre ton temps à faire des trucs qui ne font pas beaucoup gagner.