Discussion :

[kobe]

Bonjour,

je suis en train de créer une petite appli avec des tâches lancées par différents thread qui s'executent.
Ce que j'aurais voulu, c'est pouvoir comparer le temps d'execution de ces threads en lancant une sorte de compteur à leur début, ce dernier s'arrétant une fois les traitements du thread terminé.

Comment dois-je procéder pour avoir une mesure assez fiable pour chaque thread?

Merci d'avance!

[mavina]

Dans ton thread tu as une fonction run qui s'execute au début de ton thread et qui s'arrette à la fin de ton thread.
Au début de cette fonction, mémorise dans un long System.currentTimeMillis() , et comparle le à ce meme System.currentTimeMillis() juste avant que ton thread ne s'arrette.


ca donnera a peu près ca :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
class MaClasse implements Runnable
{
 
  MaClasse()
  {
    (...)
  }
  public void run()
  {
    long timeTest = System.currentTimeMillis();
    (... Traitement ...)
    timeTest = System.currentTimeMillis()-timeTest;
  }
(...)
}

voila voila

bon courage

mavina

[Gfx]

currentTimeMillis() n'est pas si fiable que cela. Si tu utilises Java 1.5 ou 1.6, tu peux appeler nanoTime(). Enfin tu peux tout simplement utiliser un profiler comme celui de NetBeans (gratuit, disponible sur netbeans.org). Le profiler te permet de faire plus de choses.

[mavina]

Ah c'est pas fiable ? Au temps pour moi ;-\

[kobe]

Ok merci pour ces infos, je vas m'y pencher!

[Gfx]

En fait cela dépend de l'OS. Par exemple Windows a une résolution de timer de 15 millisecondes. Autrement dit, si tu fais 2 appels à currentTimeMillis() en moins de 15 ms, tu obtiendras 0 ms de différence.

[mavina]

Ouais c'est assez... embettant tout de même

[Gfx]

D'où ma remarque sur nanoTime et un profiler.

[Glob]

Hello.

Si currentTimeMillis n'est pas très précis, il est toujours possible de faire exécuter x fois le traitement, de mesurer une fois avant et une fois après, et de faire une moyenne...

[mavina]

le probleme c'est que si tu es sous java 1.4.2 (c'est pour ma part le cas), bah tu esun peu coincé, je vais regarder pour ton profiler, ca m'intrigue

edit pour au dessus : moui à la limite tu auras toujours une marge d'erreur de 15 ms, ce qui peut dans certains cas etre enorme ^^

[adiGuba]

Salut,

Autrement dit, si tu fais 2 appels à currentTimeMillis() en moins de 15 ms, tu obtiendras 0 ms de différence.

Voir même 15ms si tu fais tes deux appels juste avant/après le raffraichissement du timer...

J'ai même souvent remarqué des "erreurs" pouvant aller jusqu'à 32ms...

a++

[kobe]

Ok je viens de tester avec nano, mais quelque chose me chiffonne en fait...
Si je lance plusieurs thread sous mon OS windows, et que je mesure le temps d'execution de chacun, comment pourrais-je avoir un résultat fiable puisque si j'ai bien compris le principe des thread, windows réparti a sa manière un peu de temps pour chaque thread...donc le temps que j'obteindrais ne se ra pas bon puisque qu'entre temps le thread aura été interrompu mais son traitement ne sera pas terminé pour autant...
Est-ce que je me trompe ou pas?

[mavina]

Si tu ne précise rien, aucune priorité n'est appliquée à chaque thread par la VM, donc ils sont exécutés "equitablement" normalement ^^

When code running in some thread creates a new Thread object, the new thread has its priority initially set equal to the priority of the creating thread

[BugFactory]

Si je ne me trompe pas, la classe ThreadInfo a quelques méthodes qui pourraient vous être utile.

[kobe]

En effet, je lance mes thread sans aucune priorité, et je ne savais pas que le temps était équitablement réparti, merci pour l'info!
Je vais regarder ce qu'il y dans la classe threadinfo! Mais a quoi sert-elle?

[kobe]

Désolé de fare remonter ce "vieux" topic, mais je n'ai pas résolu mon pbm dans le sens ou si j'arrive bien a mesurer le temps lors de l'execution normale, ça se gate lorsque je veux faire des pauses dans mes threads... De ce fait, j'aurais plus besoin d'une sorte de chronométre que de mesurer le temps au début du threa et de le soustraire au temps relevé à la fin du thread...
Vou avez une idée sur ce que je pourrais utiliser?

[®om]

Salut,

Voir même 15ms si tu fais tes deux appels juste avant/après le raffraichissement du timer...

J'ai même souvent remarqué des "erreurs" pouvant aller jusqu'à 32ms...

a++

Une fois j'avais fait un prog de test pour afficher System.currentTimeMillis() en boucle... Et les différences allaient jusqu'à plus de 100ms de différence...
Par exemple (valeurs bidons):
123000000
123000000
123000000
123000000
123000000
123000172
123000172
123000172
123000172
123000172
123000305
123000305
...

Je ne connaissais pas nanoTime(), merci

le probleme c'est que si tu es sous java 1.4.2 (c'est pour ma part le cas), bah tu esun peu coincé, je vais regarder pour ton profiler, ca m'intrigue

En même temps, pourquoi rester sous 1.4.2?

[kobe]

Personne n'a une petite idée pour moi? Parce que la honnétement je trime dur, impossible de mesurer le temps efficacement lorsque je met mon thread en pause...

[jowo]

Bonjour,

Si tu es sous Java 1.5, tu as la classe ThreadInfo.

Sinon, il ne reste plus que les APIs de l'OS via JNI.

La plupart des OSs ont des APIs permettant de connaître certaines informations des threads sauf si JAVA gère son propre système de threads.

Sans indiscrétion, pourquoi désires-tu connaître le temps d'éxecution?

[kobe]

Merci jowo!

En fait je lance plusieurs thread qui traitent des données et qui doivent arriver au même résultat, la différence étant que chacun d'eux utilise une méthode différente pour y arriver. Donc, je veux mesurer le temps pour savoir quel thread est le plus rapide pour effectuer son traitement, sachant que les thread partent en même temps.

Bon, pour cette mesure de temps, ça marche avec ce qui m'a gentiment été soufflé par ceux qui ont répondu, seulement je veux mettre en pause tous ces threads à l'aide d'un bouton (ça n'a aucun interet certes mais c'est pour tester la méthode). Du coup, il est clair que la mesure du temps n'est plus correcte puisqu'il y a le temps de la pause (ou des pauses) à retirer du temsp total mesuré dans le run() du thread...

Voila tu sais tout!

Sinon oui je susi bien sous Java 1.5, mais j'ai pas l'impression que threadInfo me soit d'une grande utilité...