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.