[MFC] Threads plus lent que process

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...:aie:

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.8O

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é :roll:

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

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 ?

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.

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 :ccool:

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 :D

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

Citation:

---

Envoyé par goestrip

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

---

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.