Discussion :

[totoscill]

Bonjour,

Je developpe une application MFC. Je trouve que mon application utilise beaucoup de charge CPU (il y a beaucoup de boucle). J'ai entendu dire qu'il existait une fonction qui permettai de "rendre la main" � Windows un certain temps et donc de diminuer la charge CPU.

Quelqu'un en � t il d�j� entendu parl� et quelle est cette fameuse fonction?

Je vous remercie.

[Mac LAK]

Si tu veux parler de Sleep, �a ne changera pas grand-chose... Si ton appli bouffe beaucoup de CPU, tu as en g�n�ral les raisons suivantes :

• C'est normal, tu fais un traitement "lourd".
• Tu bloques la boucle de messages Windows, et ton application se "fige" tant que tu n'as pas fini ton traitement. Lancer des threads pour r�soudre �a.
• Tu effectues des appels en attente active. Par exemple, boucler sur une lecture depuis une socket au lieu d'utiliser les �v�nements et/ou les lectures bloquantes.

Au pire, essaie de faire un profilage du code et rep�re la fonction la plus consommatrice de temps machine, que tu posteras ensuite ici... Mais il te faut les outils ad�quats, et �a d�pend de ta version de Visual utilis�e h�las.

[totoscill]

Si tu veux parler de Sleep, �a ne changera pas grand-chose... Si ton appli bouffe beaucoup de CPU, tu as en g�n�ral les raisons suivantes :

• C'est normal, tu fais un traitement "lourd".
• Tu bloques la boucle de messages Windows, et ton application se "fige" tant que tu n'as pas fini ton traitement. Lancer des threads pour r�soudre �a.
• Tu effectues des appels en attente active. Par exemple, boucler sur une lecture depuis une socket au lieu d'utiliser les �v�nements et/ou les lectures bloquantes.

Au pire, essaie de faire un profilage du code et rep�re la fonction la plus consommatrice de temps machine, que tu posteras ensuite ici... Mais il te faut les outils ad�quats, et �a d�pend de ta version de Visual utilis�e h�las.

Oui Sleep je connais. On m'avais parl� d'une autre fonction mais je ne m 'en souviens plus.
Je n'utilise pas de process vraiment "lourd" mais j'ai effectivement des boucles sur lecture de socket mais elles sont dans des Threads il me semble.

Par contre, tu me parle de profilage de code: que veux tu dire?

J'utilise Visual studio 2008 version pro.

[Mac LAK]

Je n'utilise pas de process vraiment "lourd" mais j'ai effectivement des boucles sur lecture de socket mais elles sont dans des Threads il me semble.

Ce n'est pas parce qu'elles sont dans des threads qu'elles ne carbonisent pas le CPU... Tes threads de lecture depuis les sockets doivent occuper ZERO POURCENT de charge CPU lorsque tu n'as aucune donn�e pr�tre. Si ce n'est pas le cas, c'est que tes lectures ne sont pas bloquantes, donc c'est "mal".

Par contre, tu me parle de profilage de code: que veux tu dire?

Analyser le code (via des outils automatiques) afin de savoir combien de temps CPU chaque fonction bouffe dans le programme.

J'utilise Visual studio 2008 version pro.

Je ne crois pas qu'il y aie une fonction de profilage dans cette version, il me semble que ce n'est que dans la version "Development" et au dessus...

[totoscill]

Ce n'est pas parce qu'elles sont dans des threads qu'elles ne carbonisent pas le CPU... Tes threads de lecture depuis les sockets doivent occuper ZERO POURCENT de charge CPU lorsque tu n'as aucune donn�e pr�tre. Si ce n'est pas le cas, c'est que tes lectures ne sont pas bloquantes, donc c'est "mal".

Analyser le code (via des outils automatiques) afin de savoir combien de temps CPU chaque fonction bouffe dans le programme.

Je ne crois pas qu'il y aie une fonction de profilage dans cette version, il me semble que ce n'est que dans la version "Development" et au dessus...

Je suis d'accord avec toi mais normalement une lecture sur une socket est bloquante donc pas de probl�me. Un autre process qui doit me prendre de la charge CPU est la mise � jours de l'IHM.

[Mac LAK]

Je suis d'accord avec toi mais normalement une lecture sur une socket est bloquante donc pas de probl�me. Un autre process qui doit me prendre de la charge CPU est la mise � jours de l'IHM.

V�rifie quand m�me pour tes sockets : mets un breakpoint apr�s la lecture, n'envoie AUCUNE donn�e. Si tu t'arr�tes sur tes BP, c'est pas bon. Si effectivement d�s que tu envoie les BP se d�clenchent, alors c'est qu'elles sont bien bloquantes.

Sinon, c'est un thread plut�t qu'un processus, je pense... Si c'est un processus, c'est visible directement dans le gestionnaire de t�ches.
Ensuite, c'est justement le profilage qui te permet de savoir quel thread / fonction carbonise le temps CPU...

[totoscill]

V�rifie quand m�me pour tes sockets : mets un breakpoint apr�s la lecture, n'envoie AUCUNE donn�e. Si tu t'arr�tes sur tes BP, c'est pas bon. Si effectivement d�s que tu envoie les BP se d�clenchent, alors c'est qu'elles sont bien bloquantes.

Sinon, c'est un thread plut�t qu'un processus, je pense... Si c'est un processus, c'est visible directement dans le gestionnaire de t�ches.
Ensuite, c'est justement le profilage qui te permet de savoir quel thread / fonction carbonise le temps CPU...

Ok, merci. Je regarde ca.