Discussion :

[visiwi]

Bonjour,

Qu'elle le compilateur le plus performant ? J'entends par "performant" celui qui donnera le code le plus optimisé, rapide.

Par exemple, j'ai "entendu dire" (le net...), que le compilateur d'Eclipse est moins performant (suivant la définition plus haut) que javac !

Peut-on s'attendre, lorsque l'on compile en binaire, a ce que l'application soit toujours plus rapide ? Gagne-t-on beaucoup en terme de vitesse ?

[Invité]

Salut,
Je pense que le JIT compiler est plus important pour la rapidité. le compilo de sun peut peut-être effectuer des optimisations que le compilo d'eclipse ne fait pas, mais je ne connais pas les différences fondamentales...

[visiwi]

Merci de ta réponse. Je ne connais pas JIT (just in time je crois), je vais me renseigner.

Difficile de savoir comment rendre son appli plus rapide...

[adiGuba]

Salut,

Merci de ta réponse. Je ne connais pas JIT (just in time je crois), je vais me renseigner.

C'est le compilateur "Just In time", intégré à la JVM, et qui compile le bytecode en natif à l'exécution... donc cela n'a rien a voir avec la phase de compilation des sources...

Difficile de savoir comment rendre son appli plus rapide...

Avant de se pencher sur les compilateurs, il serait préférable de se pencher sur le code !
Si ton application a des problèmes de performances, il y a peu de chance que ce soit à cause du compilateur

a++

[Invité]

Salut,


C'est le compilateur "Just In time", intégré à la JVM, et qui compile le bytecode en natif à l'exécution... donc cela n'a rien a voir avec la phase de compilation des sources...

Oui c'est ce que je voulais dire en effet... Peut-être me suis je mal exprimé

[visiwi]

Ok, pour JIT.

Avant de se pencher sur les compilateurs, il serait préférable de se pencher sur le code !

Mon appli n'a pas de problème de performance, le code est sain et optimisé.
Je cherche la petite bête , en voulant compiler avec un compilateur qui optimise "au mieux" le byte-code ! Et aussi obtenir des informations a ce niveau pour connaissance perso.

[adiGuba]

Ben justement les principales optimisations sont effectué à l'exécution et non pas lors de la phase de compilation standard. Je ne pense donc pas qu'il y ait une grosse différence entre eclipse JDT et javac...

La différence se fait donc vraiment dans le code, voir dans le tuning du GC si on a des besoins bien spécifiques...

Mais bon je vois mal l'intérêt de toucher à un code sain et optimisé.

a++

[visiwi]

Ben justement les principales optimisations sont effectué à l'exécution et non pas lors de la phase de compilation standard. Je ne pense donc pas qu'il y ait une grosse différence entre eclipse JDT et javac...

Je vais me faire des tests, pour me faire ma propre idée. Mais je pense que tu as raison, les différences (si il y en a) sont surement minime.

Sinon, est-ce que l'utilisation d'un obfuscator permet un accroissement des performances ?

[adiGuba]

Sinon, est-ce que l'utilisation d'un obfuscator permet un accroissement des performances ?

Heu... pourquoi cela améliorerait les performances ????


a++

[visiwi]

Heu... pourquoi cela améliorerait les performances ????

Parce que j'ai lu que cela accélérait le chargement des classes et diminuait l'utilisation de la mémoire.
Outre le fait que cela diminue aussi la taille du jar et que le code est plus difficile a comprendre.

J'aurais voulu savoir si ces infos sont exactes.

[adiGuba]

Tu pourrais citer tes sources ?

Parce que je ne vois pas vraiment en quoi l'obfuscation pourrait améliorer les perfs

a++

[visiwi]

Tu pourrais citer tes sources ?

Oui bien sur, j'ai trouvé ces affirmations ici. Ce que tu peux aussi lire sur le site de proguard.

Ai-je mal compris ? Cela est-il faux ?

[adiGuba]

ProGuard n'est pas un simple obfuscateur, comme indiqué :

ProGuard is a free Java class file shrinker, optimizer, obfuscator, and preverifier.

Pour ce qui est indiqué dans le premier lien, je vois deux points :

• Les noms de méthodes/variables qui sont renommé pour utilisé des noms plus courts. Cela a surement un impact sur la taille du *.class, mais je doute que cela en ai sur les temps d'exécution...
• Les optimisations du fichiers sources concernent un code vraiment pourri où l'on multiplies les opérations pour rien...

Par curiosité j'ai quand même testé cela, entre la version non-optimisé :

Code :

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

1
2
3
4
5
    public static final int strengthReduction1() {
        int a = 10;
        a = a + 0;
        return a;
    }

Et son équivalent optimisé par ProGuard :

Code :

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

1
2
3
    private static int b() {
        return 10;  
    }

Pour tester j'ai utilisé ce code :

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
17
18
19
20
21
		final int N = Integer.MAX_VALUE;
		final int O = 5;
 
		for (int x=0; x<O; x++) {
			long start = System.nanoTime();
			int v = 0;
			for (int i=0; i<N; i++) {
				v += strengthReduction1();
			}
			long end = System.nanoTime();
			System.out.println(" standard  ==> " + (end-start) + " ns");
		}
		for (int x=0; x<O; x++) {
			long start = System.nanoTime();
			int v = 0;
			for (int i=0; i<N; i++) {
				v += b();
			}
			long end = System.nanoTime();
			System.out.println(" optimized ==> " + (end-start) + " ns");
		}

Je boucle 5 fois pour chaque test, car les premiers passages sont souvent "polluer" par le compilateur JIT, et qu'un large échantillon de résultat est plus probant. Cela me donne ceci :

Code :

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

1
2
3
4
5
6
7
8
9
10
 standard  ==> 1827058690 ns
 standard  ==> 1809185978 ns
 standard  ==> 1809340188 ns
 standard  ==> 1808870630 ns
 standard  ==> 1808155217 ns
 optimized ==> 1813815087 ns
 optimized ==> 1809827982 ns
 optimized ==> 1808923700 ns
 optimized ==> 1808456143 ns
 optimized ==> 1809867373 ns

Dans les deux cas on tourne autour de 1,808 secondes... et cela pour plus de 2 millions d'appels de méthode.

Donc j'ai du mal à penser que cela donne une différence flagrante sur une application réelle...



Bref, c'est peut-être parfait pour diminuer la taille des fichiers *.class, mais je ne pense pas que la différence de performance à l'exécution soit sensible.


a++

PS : Attention également à ne pas utiliser cela sur une librairie ou des classes utilisant la reflection, car cela pourrait tout casser du fait du renommage...