IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Threads & Processus C++ Discussion :

[MFC] Threads plus lent que process


Sujet :

Threads & Processus C++

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Futur Membre du Club
    Inscrit en
    Février 2010
    Messages
    4
    Détails du profil
    Informations forums :
    Inscription : Février 2010
    Messages : 4
    Par défaut [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...

    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é

  2. #2
    Expert éminent
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2005
    Messages
    27 395
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2005
    Messages : 27 395
    Par défaut
    Fais-tu appel à quelque chose qui est un tant soi peu partagé, du genre la console, ou autre chose lié à l'interface utilisateur?
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  3. #3
    Futur Membre du Club
    Inscrit en
    Février 2010
    Messages
    4
    Détails du profil
    Informations forums :
    Inscription : Février 2010
    Messages : 4
    Par défaut
    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 ?

  4. #4
    Expert éminent
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2005
    Messages
    27 395
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2005
    Messages : 27 395
    Par défaut
    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.
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  5. #5
    Futur Membre du Club
    Inscrit en
    Février 2010
    Messages
    4
    Détails du profil
    Informations forums :
    Inscription : Février 2010
    Messages : 4
    Par défaut
    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

  6. #6
    Futur Membre du Club
    Inscrit en
    Février 2010
    Messages
    4
    Détails du profil
    Informations forums :
    Inscription : Février 2010
    Messages : 4
    Par défaut
    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

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. [std::thread] Algorithme plus lent que en simple thread
    Par Trademark dans le forum Threads & Processus
    Réponses: 24
    Dernier message: 17/04/2013, 10h52
  2. Réponses: 76
    Dernier message: 29/03/2011, 16h15
  3. [MFC] theApp, plus lent que le reste?
    Par giova_fr dans le forum MFC
    Réponses: 4
    Dernier message: 23/02/2006, 12h06
  4. [Firebird][Optimisation]Plus lent que le BDE!
    Par vincentj dans le forum Débuter
    Réponses: 3
    Dernier message: 07/02/2005, 15h48
  5. DBExpress est plus lent que BDE?
    Par palassou dans le forum Bases de données
    Réponses: 4
    Dernier message: 02/07/2004, 08h39

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo