Discussion :

[kreeks]

Bonjour tout le monde,
je travaille actuellement sur un outil assez gourmand en temps de calcul.
jusqu'à peu seule une version console de mon outil existait, et j'ai créé une interface avec wxwidgets afin de la rendre plus pratique pour l'utilisateur.
l'interface est très simple quelques bouton et des file et dir picker, ainsi qu'une seule de texte (peu utilisé) et malgré la légèreté de cette interface et le fait que les traitements sont les mêmes (les mêmes class C++ sont utilisés et de la même façon), les temps de traitement sont beaucoup plus long (2 à 4 fois plus)

je cherche donc à savoir pourquoi wxWidget augmente autant mes traitements? les objets standart du C++ serait surchargé et plus long?

merci de me dire si quelqu'un aurait une piste.

(sinon en annexe je n'arrive pas à redirigé mes sortie standart "cout" dans un wxTextCtrl même après avoir modifié le flag wxUSE_STD_IOSTREAM et recompiler wxWidget)

[AlexisA]

les temps de traitement sont beaucoup plus long (2 à 4 fois plus)

Il n'y a aucune raison. Le temps de calcul ne varie pas si on invoque les routines de calcul par une IHM. Sauf bien sûr si l'IHM est mal programmée et pompe du temps CPU.

Quel compilateur et quel IDE utilisez-vous ?

Si vous êtes sous Visual C++, vérifiez bien que votre programme console n'est pas compilé en "release" et que votre programme IHM n'est pas en "Debug". wxWidgets utilise en debug les facilités de Visual C++ permettant de détecter les fuites de mémoire, débordement de tableau, etc...
Ce mode debug ralentit considérablement l'exécution, parfois d'un facteur 10.

[kreeks]

Il n'y a aucune raison. Le temps de calcul ne varie pas si on invoque les routines de calcul par une IHM. Sauf bien sûr si l'IHM est mal programmée et pompe du temps CPU.

Quel compilateur et quel IDE utilisez-vous ?

Si vous êtes sous Visual C++, vérifiez bien que votre programme console n'est pas compilé en "release" et que votre programme IHM n'est pas en "Debug". wxWidgets utilise en debug les facilités de Visual C++ permettant de détecter les fuites de mémoire, débordement de tableau, etc...
Ce mode debug ralentit considérablement l'exécution, parfois d'un facteur 10.

environnement: windows (mais avec version linux prévu) IDE : eclipse/CDT & compilateur : g++
Effectivement les options de compilation été en cause, le paramètre d'optimisation n'était pas au même niveau, après avoir recompiler avec l'option -O3 au lieu de -O0 j'ai divisé par 2 le temps de traitement.

Mais ça n'ai donc pas la seule raison, car avant optimisation à la compil les traitement étaient en moyenne 4 fois plus long, désormais ce n'est plus que 2, mais ce n'est pas rien et les traitement étant les mêmes => ce n'est pas compréhensible.

je ne pense pas que l'interface IHM sauf en cause, elle est tellement basique qu'elle peut être difficilement gourmande, en plus les graphiques d'utilisation processeur sont très similaire entre la version console et la version graphique => je comprends pas trop.

en tout cas merci pour ta réponse

[AlexisA]

Effectivement les options de compilation été en cause, le paramètre d'optimisation n'était pas au même niveau, après avoir recompiler avec l'option -O3 au lieu de -O0 j'ai divisé par 2 le temps de traitement.

Bon, j'ai contribué à faire avancer les choses, c'est déjà ça !

et les traitement étant les mêmes => ce n'est pas compréhensible.

Eventuellement, poste ton code source sur le forum (en remplaçant les calculs par des fonctions bouchons si c'est confidentiel) pour examen.

[3DArchi]

Bonjour,
As-tu essayé de diviser ton code en 2 threads : un pour tout ce qui est IHM et accès lent (fichier, réseaux, cartes...) et un pour les calculs purs. Il est possible que la perte de temps soit liée à des fonctions 'lentes' d'I.H.M., d'envoi de message, etc.