CALCULER LES PERFORMANCES DES THREADS

Information sur la source

Catégorie :Système Classé sous : TThread, GetThreadTimes, TFileTime, multithreading, performances Niveau : Débutant Date de création : 02/03/2008 Date de mise à jour : 11/03/2008 21:26:13 Vu / téléchargé: 1 830 / 134

Auteur : Caribensila

Ecrire un message privé

Ce membre participe au partage de revenus publicitaires

Note :

10,00 / 10

Commentaire sur cette source (21)

Ajouter un commentaire et/ou une note

Description

Voici une petite procédure qui vous permettra de mesurer exactement le temps d'occupation du CPU par vos Threads.

Elle permet de savoir, pour chaque thread :
- Sa date de création
- Sa date de fin
- Le temps d'occupation du processeur
- Le mode dans lequel il a utiliser le processeur (Utilisateur ou Superviseur)
Voir ce topic pour plus de précisions :
http://www.delphifr.com/infomsg_KERNELTIME-USERTIME_1085278.aspx

Toutes ces informations utilisées à bon escient permettront par exemple de savoir combien de temps une application tourne, quel thread est le plus souvent demandé, etc... Ces informations pourront vous permettre d'effectuer des mises à jour plus fines car vous saurez ce qui fait ralentir l'application et ce que vous devez optimiser. L'adaptation de cette procédure à vos besoins devrait être très facile.

Conclusion

Bien sûr, pour utiliser la procedure GetThreadStats(), il faut que le Thread soit terminé mais pas encore libéré. Donc
MonThread.FreeOnTerminate := false;

Ensuite, il suffit de lui passer le handle d'un Thread dont on veut mesurer les performances et une chaîne pour l'identifier. On le libèrera juste après :
GetThreadStats(MonThread.Handle,'Mon thread');
MonThread.Free;

La démo est minimaliste, mais elle permet cependant d'effectuer certaines expériences très intéressantes sur les Threads, en particulier l'étude de l'influence des priorités. On découvre des trucs surprenants !

Un grand merci à WhiteHyppo qui a éclairé ma lanterne.

Fichier Zip

Pour les "Membres Club", vous pouvez télécharger directement un fichier contenu dans le zip sans télécharger le zip en entier !

ThreadPerf
- MainU.dfm658 octets
- MainU.pas 3 049 octets
- ProgressFormU.dfm489 octets
- ProgressFormU.pas 385 octets
- ThreadTimes.dpr 285 octets
- ThreadU.pas 1 868 octets

Télécharger le zip

Historique

02 mars 2008 21:35:20 :: Il est obligatoire d'écrire un truc ici. Alors, j'écris. :)
03 mars 2008 13:37:48 :: Ajout d'un petit mode d'emploi.
11 mars 2008 21:26:13 :: Changement du test "fin de Thread" avec un PostMessage.

Sources du même auteur

Toutes les sources de Caribensila

Sources de la même categorie

Toutes les sources de la catégorie Système

Sources en rapport avec celle ci

LA DANSE DES AVATARS

Commentaires

Commentaire de MAURICIO le 03/03/2008 16:17:29

Salut Cari,
je n' ai pas Delphi sous la main (juste Notepad mais j' ai vu ce que je voulais!) mais comme toutes les bonnes sources postées, celle-ci semble "désinteresser" (comprenez ici que les bonnes source demmandent un certains savoir et/ou un effort de compréhension) la majorité des membres de DelphiFr.

Pour ceux que cette source "répugne", sachez que les threads sont la base de tout appli (au moins un thread) et permettent en multithread, de ne pas bloquer la fenêtre principale à cause d' un long procédé par exemple.

Bien plus que calculer les performances des threads, cette source montre comment les utiliser et rien que pour ça, mérite d' être testée et téléchargée (aller hop, on se motive).

En tout cas moi, j' attends toujours avec impatiente tes sources (je sais que c' est frustrant de poster une bonne source sans avoir de commentaires) ...

A+
Commentaire de Caribensila le 03/03/2008 17:16:01

Salut Mauricio,

A vrai dire, je ne m'attendais pas à beaucoup de commentaires. Ce n'est qu'un petit outil qui ne peut intéresser que les gens utilisant les TThreads et qui, de plus, éprouvent le besoin de les optimiser. Ca limite fortement le nombre d'intéressés, 'faut bien le reconnaître ! lol

Il y a des sources comme ça, de temps en temps. Comme un bug sur un évènement souris traité dernièrement par Florent, ou "les arcanes d'Indy" traité par un certain Mauricio, etc. :)
L'intérêt de ces sources ne se limite heureusement pas au nombre de commentaires. On est bien tranquillisé de savoir qu'elles sont là pour le jour où on se cassera le nez sur les problèmes traités.
Rien que ça, ça vaut de l'or, non?

En tout cas, merci Mauricio. C'est très gentil et ton commentaire me fait bien plasir, 'faut bien le reconnaître aussi ! ;)
Commentaire de florenth le 03/03/2008 19:13:37

T'es fou, ça m'intéresse drôlement !
Va falloir trouver du temps pour étudier la chose... t'aurais quand même pu poster pendant les vacances lol !

J'ai moi aussi un petit détail sur ton tuto d'optimisation qui serait intéressant d'étudier de plus près: le déroulement partiel de boucles, on y apprend pas mal (j'arrive à un ratio 1,5 : 1 avec une technique toute simple mais qui nécessite quelques précautions).

Ouais, pareil que ma source sur les bugs souris, je suis sûr que ça aidera qqn tellement je me suis cassé les pieds à trouve d'où pouvait venir une fuite de mémoire !
"Rien que ça, ça vaut de l'or, non?" => euh... à ce point là ? ^^

Voila, en attendant tes nouvelles aventures...
A+
Commentaire de Caribensila le 03/03/2008 21:53:13

« Va falloir trouver du temps pour étudier la chose »
Boaf... Tu feras ça entre la thèse et l'antithèse de ta prochaine dissert' de philo sans problème. Y'a vraiment rien de terrible quand on connaît les APIs à utiliser.

Pour l'optimisation, je crois bien qu'il y a encore matière à quelques tutos. Moi aussi, je ramasse ça et là des tactiques intéressantes. Il faudra qu'on en reparle quand on sera moins emm.. par les vicissitudes de la vie. ;)
Commentaire de cantador le 03/03/2008 21:58:05

Ca y est j'ai compris un thread çà permis de partir au ski
tout en tapotant sur le forum !

Merci Caribensila, car les thread c'est ma grande passion..
j'en utilise couramment dans mes applis et j'aimerai en savoir encore plus..
et je vais regarder ton truc de près.
Commentaire de Caribensila le 03/03/2008 22:43:22

Non, Môssieur Cantador! Je ne fais pas partie de ces privilégiés qui ne codent que de la musique et qui draguent la skieuse pour les copains (si vous voyez de qui je parle?).

Moi, je vais mettre les mains dans le ciment, pour changer un peu. Je suis opticien de formation, mais finalement je préfère le bâtiment ( en plus, c'est vrai! lol )

Promis, je reparlerai des Threads à mon retour. En particulier un Thread dont on conserve le contrôle d'exécution et qui n'est donc pas préempté à tous bouts de champ par le système d'exploitation... 'me reste juste à savoir à quoi ça pourrait bien servir. lol

@ plus!
Commentaire de cantador le 03/03/2008 23:52:10

Cari les mains dans la gachée..
Qui l'eut cru ?
Donc, maintenant, on pourra t'offrir un fil à plomb !

@bientôt
Commentaire de cirec le 04/03/2008 12:51:23 administrateur CS

Je vois que tous le monde est logé à la même enseigne ...

pas ou peut d'intérêt pour des sources qui n'ont pourtant jamais étés publiés
ceci entrainant des rétentions sur des dépôts plus intéressants.

Je conserve ainsi sous le coude, depuis des mois, des sources que j'avais l'intention de déposer ici (Ex le cube que certains ici on vu) mais surtout un composant GDI+ qui s'intègre au TImage (sans installation) et qui ouvre tous les types d'images reconnues par Windows (depuis un fichier, une ressource, un stream, presse-papier) il peut les convertir dans différents formats (PNG GIF TIF JPG BMP avec Alpha Chanel ...) ,appliquer Filtres, Transparences, Rotations, Miroirs, Négatifs, luminosités, etc ... etc et bien sur on peut conserver les changements ;)

Caribensila à l'air de prendre cela comme une fatalité mais je pense au contraire que les mentalités on changées et ce depuis un certain temps et pas dans le bon sens. et je pense ne pas être le seul à avoir la même vision des choses.

Sinon c'est vrai que les Thread sont important et utiles à condition de s'en servir correctement (n'est ce pas Cantador lol) et surtout quand c'est justifié.

Encore une source bien utile qui n'est pas estimé à sa juste valeur.

@+
Commentaire de cirec le 04/03/2008 13:00:39 administrateur CS

Petit bug sur les résultats du Thread Idle
la Date de fin reste toujours la même ... et en plus le Thread s'est terminé ily a 407 années ... lollllll
---------------------------
Threadtimes
---------------------------
Nom Thread : Thread Idle
Date départ : 04/03/2008 12:56:44
Date fin        : 01/01/1601 01:00:00
KernelTime   : 0 ms.
UserTime      : 15125 ms.
GlobalTime    : 15125 ms.
---------------------------
OK
---------------------------
Commentaire de MAURICIO le 04/03/2008 13:10:18

Merci Cirec, ça rejoint ce que j' essayai de dire: c' était une sorte de coup de gueule mal exprimé ...
En ce qui concerne ton compo, il m' interesse grave mais je ne suis pas sur mes compos pour le moment: je garde au chaud! Pour les "Requisite", ça marche sous tous les Windows ton compo?

Hop, j' en profite pour voter, c' est mérité. Ça passera inaperçu mais "les esclaves" (je me comprends) que nous sommes ont besoin aussi de motivation!!!
A+
Commentaire de cirec le 04/03/2008 13:16:36 administrateur CS

J'avais bien compris ton coup de gueule que je partage à 200% ...

Oui il fonctionne sous toutes les versions Windows il suffit de fournir GDIPlus.DLL avec ton application pour les Win98 et autres qui en seraient dépourvus

Oui c'est vrai que c'est mérité et tanpis si ça passe inaperçu
Commentaire de cirec le 11/03/2008 12:23:06 administrateur CS

@Caribensila
Alors ... Bug ou pas bug sur les résultats du Thread Idle ??
Commentaire de Caribensila le 11/03/2008 19:16:39

Oh! Excuse-moi Cirec. J'avais zappé ton problème. :s
Mais avant tout, je crois que tu devrais penser à faire exorciser ton PC. VADE RETRO SATANAS ! :D

Plus sérieusement. J'avais effectivement rencontré ce bug quand je développais ce petit source. Le problème venait du fait que le thread n'était pas tout à fait terminé lors de la mesure avec l'API GetThreadTimes(). J'avais essayé diverses techniques pour déceler la fin d'un Thread, et je m'étais arrêté à la méthode OnTerminateProcedure() du Thread qui, chez moi, avait résolu le problème.
Je ne sais pas pourquoi ce bug ressurgit chez toi. Mais bon...
Je vais essayer d'autres techniques pour effectuer les mesures quand le Thread est vraiment terminé.
J'essaie, je poste et je te préviens...

PS: "01/01/1601" signifie que la Date De Fin = 0. La définition de TFileTime est assez étrange. C'est codé sur 64 bits et ça symbolise le nombre de centaines de nano-secondes (?) écoulées depuis le 1er janvier 1601 (?).
Donc il n'est pas étonnant que ça bugue avec ce type, assez ancien. ;)
Commentaire de Caribensila le 11/03/2008 21:35:09

Voilà. J'ai reposté.
Je teste la fin du Thread avec un PostMessage maintenant.
Ca devrait marcher.
Commentaire de cirec le 11/03/2008 22:40:07 administrateur CS

Désolé
---------------------------
Threadtimes
---------------------------
Nom Thread : Thread Idle
Date départ : 11/03/2008 22:34:43
Date fin        : 01/01/1601 01:00:00
KernelTime   : 0 ms.
UserTime      : 8792,6432 ms.
GlobalTime    : 8792,6432 ms.
---------------------------
OK
---------------------------

et j'ai, entre temps, changé de PC et de version de Delphi !!!
C'est peut être l'appartement qui est hanté ... ou moi  Mdrrrr
Commentaire de Caribensila le 12/03/2008 02:06:21

Quel effroi ! ! !
Je n'avais pourtant pas oublié les oeufs de caille pourris...
- Dis, Jacquouille? T'avais pas un rôle dans "Les Visiteurs"? mdrrr

Pas facile de corriger un bug que je n'ai pas chez moi...
Et tu n'envisagerais pas de changer de région par hasard? (passe que je ne sais plus quoi faire, moi.)
Commentaire de MAURICIO le 12/03/2008 10:11:58

Que je trépasse si je faibli mais il me semble qu' un TDateTime = 0 pour la date 01/01/1899 ou alors je dois changer de PC aussi ^^
A+
Commentaire de Caribensila le 12/03/2008 14:07:52

... Je parlais d'un FileTime, mon p'tit fillot ;)
GetThreadTimes() renvoie un FileTime, parce que ce serait trop simple avec un TDateTime.

The FILETIME structure is a 64-bit value representing the number of 100-nanosecond intervals since January 1, 1601.

typedef struct _FILETIME { // ft
    DWORD dwLowDateTime;
    DWORD dwHighDateTime;
} FILETIME;
Commentaire de MAURICIO le 12/03/2008 14:31:05

Excuse moi mon bon maitre.
Tans mieux, j' ai pas à changer mon PC.
Commentaire de Caribensila le 12/03/2008 22:30:03

@Mauricio
En parlant ciné, j'espère que tu iras voir "Bienvenue chez les Ch'tis" et que ça te rappellera de bons souvenirs. ;)

@Cirec
Palsambleu, ça me turlupine ce bug!
Ca pourrait (peut-être) venir du fait que tu as et avais un PC multicore, contrairement à moi.
Si c'est le cas, essaie de slasher la ligne "sleep(5);" dans la procédure "TMainForm.btnLancerThreadsClick(Sender: TObject)".

Si ça ne marche pas, je ne vois vraiment pas d'où ça pourrait venir ce bug.
Commentaire de MAURICIO le 13/03/2008 10:04:51

@Cari
Vu que j' habite le Portugal, je vais devoir attendre qu' il sorte sur TF1!!! Sinon j' ai entendu parlé du film, j' ai même vu la bande annonce. ^^