Discussion :

[ilellouc]

Bonjour,

j'ai réalisé un tri en java, et je veux étudier les perfomance de ce tri.

Ainsi je réalise des tests :

Code :

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

1
2
3
4
5
6
7
8
9
 
for(int i=0;i<10;i++){
	Tri test=new Tri();
	dateD=Calendar.getInstance();
	test.tri3(0,test.taille,2,test.moyenne(0,test.taille-1));
	dateF=Calendar.getInstance();
	double temps=dateF.getTimeInMillis()-dateD.getTimeInMillis();
	System.out.println(temps);		
}

En gros ça donne ça, avec différents paramètre de taille de la liste.

Ce que je ne comprend pas, c'est que les résultats sont les suivants :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
3250.0
766.0
765.0
578.0
578.0
578.0
593.0
578.0
578.0
594.0

Au delà de l'algorithme, est-ce que la machine garde en mémoires certaines choses pour aller plus vite lors d'une nouvelle exécution ?
J'ai l'impression que mes tests sont indépendants !

Pour info, je génère à chaque fois une nouvelle liste avec des double aléatoire (du moins j'espère ^^) :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
public Tri(){
	Calendar date;
	Random rand=new Random();
	liste=new double[taille];
	for(int i=0;i<taille;i++){
		date=Calendar.getInstance();
		rand.setSeed((long)(date.getTimeInMillis()*Math.random()));
		liste[i]=rand.nextDouble();
	}
}

Quelqu'un a une explication ?

Merci

[Alkhan]

bonjour,

il est normal que tu es une différence avec le premier test, car la machine virtuelle charge en mémoire les différentes classes utilisées par ton test.

[professeur shadoko]

effet classique des optimisations dynamiques:
la première exécution est plus lente puis "ça chauffe" et ça s'optimise, ensuite les différences sont normales.

[adiGuba]

Il y a 3 principaux éléments qui peuvent impacter le temps :

• Le chargement des classes.
  La première fois que tu utilises une classe elle doit être chargé par le classloader.
  
• Le Garbage Collector.
  Le GC libère la mémoire par bloc, en bloquant temporairement le programme.
  
• La compilation HotSpot.
  La machine virtuelle détecte les parties "chaudes" (les plus utilisés) afin de les recompiler en natif avec plusieurs optimisations.

Tu peux surveiller tout cela avec les options suivantes de la JVM (pour la JVM de Sun) :

Code :

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

-XX:+TraceClassLoading -XX:+PrintGC -XX:+PrintCompilation

Enfin, il faut noter que la JVM server (option -server) offre généralement une compilation plus poussé que la JVM client (option -client).
Par défaut le choix entre client/serveur dépend de la version de Java et du système hôte...

a++

[dingoth]

Il est également possible que le tri soit plus performant sur des valeurs triées, ce qui est toujours le cas après le premier tri... car malheureusement, tu réinitialises les valeurs uniquement dans le constructeur, mais tu n'appelles le constructeur qu'une seule fois.

L'idéal est d'avoir un tableau auquel tu ne touches pas, et que tu clones avant chaque tri afin d'avoir toujours le même tableau.

[ilellouc]

Merci pour vos réponses, j'y vois plus claire.

Par contre, je pense appeler mon constructeur à chaque itération de ma boucle for, donc à chaque fois j'ai des valeurs différentes, nan ?

Donc si je veux comparer les performances de différents tris, le mieux est de comparer les premiers résultats, ou les derniers ?