Discussion :

[goestrip]

Bonjour � tous,

Je developpe sous XP sp2 32bit, avec visual 2005 et j'utilise ses MFC.
Mon application prend en entr� un fichier, travail dessus, et me pond un fichier en sortie

Comme j'ai plein de fichier diff�rents � traitier, j'ai voulu multithread�, et donc lancer plusieurs de ces traitements de fichier, chacun dans un thread diff�rent.

Je n'ai pas de probleme de synchro entre threads car ils travaillent vraiment chacun sur des fichiers diff�rents, en entr� comme en sortie.

d�s que j'ai eu multithread� la chose, j'ai commenc� � avoir de grave probleme de performance. A savoir que pour traiter 2 fichiers en meme temps (par exmple) le temps total de l'op�ration doublait par rapport au temps unitaire de traitement de chaque fichier...

J'ai alors lanc� plusieurs instance de mon application, et ne lancant cette fois ci, qu'un thread par application ( = par processus, si je ne m'abuse?)
et l�, au mystere, chaque appli traite son fichier tres rapidement.

Donc voila ma question: qu'est ce qui pourait ralentir l'�x�cution de plusieurs thread au sein d'un meme process?

j'ai suivis plusieurs piste, tout d'abord celle de l'utilisation intensive de container MFC (CListe, CMap) que j'ai remplac� par leur pendant de la STL, bof , le gain de temps fut n�gligeable.
Ensuite ( et l� je suis tomb� sur le cul) j'ai virer mes TRY/ CATCH (en majuscule hein, la version MFC toujours), et l�, �h bonheur, j'ai grandement r�duit le temps d'�x�cution des multiThreads au sein d'un meme process !!!
mais pas encore suffisament, ca reste inf�rieur au 4x 1process.

[edit1]
j'ai tent� de modifi� le StackSize dans le lancement de mes threads par AfxBeginThread(), j'ai essay� plusieurs valeurs : 0 (par defaut) , 1Ko, 10 Ko, 1Mo. Rien n'y fait, les temps sont toujours aussi mauvais.
[\edit1]

voila, si quelq'un � la moindre id�e, je suis interess�

[M�dinoc]

Fais-tu appel � quelque chose qui est un tant soi peu partag�, du genre la console, ou autre chose li� � l'interface utilisateur?

[goestrip]

non je ne crois pas, ce sont juste des threads de travails, sans autre connexion avec l'ext�rieur que la lecture/�criture dans des fichiers ( diff�rents pour chaque thread)

Est-ce que le fait d'instancier beaucoup d'objets au cours de mes traitements pourrait avoir un impact lorsque les threads sont dans le meme process ?

[M�dinoc]

Ben, il n'y a (originellement) qu'un seul tas par processus, prot�g� par un mutex interne. Donc, si tu fais plein de new/delete, le processus ne peut pas tout faire en m�me temps.
Ce serait une bonne explication sur la lenteur par rapport � des processus s�par�s.

[goestrip]

Les r�sultats te donnent raison je pense. Magr� tous mes test de perf, avec chronom�trage � l'appuie, je n'ai pas r�ussi � isoler une fonction en particulier qui prendrait plus te temps. Chaque �tape de mon traitement est juste plus lente quand les threads se partage le meme processus.

Merci de ton aide

[goestrip]

Effectivement, j'ai modifi� mon code pour essayer de faire moins d'allocation, mais de plus grosse taille, et ca a am�liorer les perf de fa�on incroyable

bref, ma conception objet �tait jolie tout plein...mais ne suffit pas, all�, on casse et on recommence

[Mac LAK]

bref, ma conception objet �tait jolie tout plein...mais ne suffit pas, all�, on casse et on recommence

Elle est peut-�tre correcte, mais simplement, c'est son impl�mentation qui est mauvaise... Il faut, quoi qu'il arrive, limiter au maximum les allocations / lib�rations en dehors des phases d'initialisation / finalisation.

Pendant le fonctionnement, si tu dois faire un new/malloc, poses-toi deux ou trois fois la question "Est-ce VRAIMENT n�cessaire ??"... La plupart du temps, tu t'en sors avec un pool d'objets et/ou des buffers g�n�riques.