Discussion :

[amira]

Bonjour
Je souhaiterais savoir si vous avez des astuces pour améliorer votre code java.

Je vais commencer par un post que j'ai trouvé sur stackoverflow et qui est vraiment pas mal :

http://stackoverflow.com/questions/1...21889#13721889

Une personne qui souhaite dans une boucle "for" réaliser une action toutes les 50 itérations écrirait un code comme celui-ci :

Code :

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

1
2
3
4
5
for (int i = 0; i < n; i++){
      if( i%50 == 0){
         Thead.sleep(200);
      }
}

Mais dans la mesure où le modulo est très gourmand en ressources, il serait préférable d'utiliser deux boucles imbriquées :

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
22
23
24
25
26
27
28
29
30
31
32
static int counter, counter2;
 
public static long testOneModLoop(int n, int m) {
    long start = System.nanoTime();
    for (int i = 0; i < n; i++) {
        counter++;
        if (i % m == m - 1)
            counter2++;
    }
    return System.nanoTime() - start;
}
 
public static long testTwoLoops(int n, int m) {
    long start = System.nanoTime();
    for (int j = 0; j < n; j += m) {
        for (int i = j; i < j + m && i < n; i++) {
            counter++;
        }
        counter2++;
    }
    return System.nanoTime() - start;
}
 
public static void main(String... args) {
    for (int i = 0; i < 5; i++) {
        int runs = 10 * 1000 * 1000;
        double time1 = (double) testOneModLoop(runs, 50) / runs;
        double time2 = (double) testTwoLoops(runs, 50) / runs;
        System.out.printf("Avg time for 1 loop: %.2f ns and 2 loops: %.2f ns%n",
                time1, time2);
    }
}

Ce qui donne en terme de temps d'exécution :

Code :

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

1
2
3
4
5
Avg time for 1 loop: 6.09 ns and 2 loops: 0.78 ns
Avg time for 1 loop: 3.75 ns and 2 loops: 0.22 ns
Avg time for 1 loop: 3.67 ns and 2 loops: 0.19 ns
Avg time for 1 loop: 3.72 ns and 2 loops: 0.19 ns
Avg time for 1 loop: 3.67 ns and 2 loops: 0.19 ns

On voit qu'entre l'utilisation du modulo et de la seconde méthode on a divisé les temps par 10 voir plus.

A vous si vous avez des astuces de codage !

[wax78]

J'ai déjà pas le même gain sur ma machine a la maison :

Code :

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

1
2
3
4
5
Avg time for 1 loop: 4,26 ns and 2 loops: 2,15 ns
Avg time for 1 loop: 4,23 ns and 2 loops: 2,15 ns
Avg time for 1 loop: 4,26 ns and 2 loops: 1,84 ns
Avg time for 1 loop: 4,30 ns and 2 loops: 1,80 ns
Avg time for 1 loop: 4,26 ns and 2 loops: 1,83 ns

et sur la machine au boulot :

Code :

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

1
2
3
4
5
Avg time for 1 loop: 4,22 ns and 2 loops: 2,18 ns
Avg time for 1 loop: 4,03 ns and 2 loops: 2,12 ns
Avg time for 1 loop: 4,07 ns and 2 loops: 1,74 ns
Avg time for 1 loop: 3,92 ns and 2 loops: 1,71 ns
Avg time for 1 loop: 3,94 ns and 2 loops: 1,71 ns

Maintenant rajoute un petit sleep dans la boucle pour simuler "un calcul"... et regarde tes temps en millisecondes

La tu te diras que tu préfères grandement garder un code lisible avec un modulo plutôt qu'une boucle découpée qui ne fait rien gagner au final...

[thelvin]

Moi j'ai des gains semblables, et en fait je trouve pas déconnant sur les machines modernes qu'un for ait été organisé de sorte d'être moins cher qu'une division entière.

Par contre, niveau lisibilité ça peut être assez mauvais, et il me semble peu intéressant d'optimiser ce point précis. Il y a forcément un travail utile fait quelque part et qui coûte plusieurs ordres de grandeur plus cher que cette petite économie.

Bon, sinon, voici une petite astuce à moi :

- String.split(String) est connu, simple et pratique...

Mais pas forcément efficace. Son paramètre est une expression de regex, String donc non compilée. Si on cherche à parser par exemple un gigantesque fichier CSV de structure simple, où toutes les lignes ont le même séparateur et que c'est un simple caractère trivial, appeler split() sur toutes les lignes va recompiler la même regex sur toutes les lignes et refaire la même analyse ultra-générale pour un pauvre caractère.
Implémenter la même chose en deux minutes à base de indexOf() et de substring() est sensiblement plus rapide.

De même assez souvent le tableau renvoyé par le split() a toujours la même taille, connue. Mais split() ne le sait pas et ne peut donc pas allouer dès le départ le tableau résultat à la bonne taille. A la place il utilise en interne une List qui s'occupe de gérer les tailles variables, puis quand le split est fini, cette List est exportée dans un tableau à la bonne taille. Ce qui fait beaucoup d'étapes inutiles et de la création d'objets à garbage-collecter, pour rien.
A nouveau, une solution qui alloue directement le tableau à la bonne taille, et le remplit à coup de indexOf() et substring(), est nettement plus rapide.

Lisible et facile, mais point chaud d'optimisation :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
long count(BufferedReader reader) throws IOException {
  long count = 0;
  for(String line = reader.readLine(); line != null; line = reader.readLine()) {
 
    // découpage
    String[] fields = line.split("-");
 
    if(fields[1].equals("on") && fields[5].equals("count")) {
      count++;
    }
  }
  return count;
}

Un peu plus d'effort, mais point chaud refroidi par rapport au travail utile.

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
22
23
24
long count(BufferedReader reader) throws IOException {
  long count = 0;
  for(String line = reader.readLine(); line != null; line = reader.readLine()) {
 
    // découpage
    String[] fields = split(line);
 
    if(fields[1].equals("on") && fields[5].equals("count")) {
      count++;
    }
  }
  return count;
}
 
static String[] split(String line) {
  String[] fields = new String[6];
  int indexString = 0;
  for(int indexArray = 0; indexArray < 6; indexArray++) {
    int nextIndex = line.indexOf('-', indexString);
    fields[indexArray] = line.substring(indexString, nextIndex);
    indexString = nextIndex+1;
  }
  return fields;
}

[amira]

En effet moi non plus je n'obtiens pas les mêmes temps, même si dans le fond ça reste quand même pas négligeable puisque je divise par trois :

Code :

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

1
2
3
4
5
6
 
Avg time for 1 loop: 15,44 ns and 2 loops: 4,31 ns
Avg time for 1 loop: 15,34 ns and 2 loops: 4,21 ns
Avg time for 1 loop: 15,29 ns and 2 loops: 3,27 ns
Avg time for 1 loop: 15,30 ns and 2 loops: 3,33 ns
Avg time for 1 loop: 15,44 ns and 2 loops: 3,28 ns

Sinon il y a une autre astuce qui marche très bien lorsqu'on utilise des String dans une boucle "for" c'est d'utiliser des "StringBuilder".

Je remanie un peu le code précédent et voici les résultats :

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
22
23
24
25
26
27
28
29
30
31
32
static int counter, counter2;
 
	public static long testOneModLoop(int n, int m) {
	    long start = System.nanoTime();
	    String concatenateString = "";
	    for (int i = 0; i < n; i++) {
	    	concatenateString += String.valueOf(i);
	    }
	    return System.nanoTime() - start;
	}
 
	public static long testOneModLoopWithStringBuilder(int n, int m) {
	    long start = System.nanoTime();
	    StringBuilder concatenateString = new StringBuilder();
	    for (int i = 0; i < n; i++) {
	    	concatenateString.append(i);
	    }
	    String output = concatenateString.toString();
	    return System.nanoTime() - start;
	}
 
 
 
	public static void main(String... args) {
	    for (int i = 0; i < 5; i++) {
	        int runs = 10 * 1000;
	        double time1 = (double) testOneModLoop(runs, 50) / runs;
	        double time2 = (double) testOneModLoopWithStringBuilder(runs, 50) / runs;
	        System.out.printf("Avg time for 1 loop: %.2f ns and 2 loops: %.2f ns%n",
	                time1, time2);
	    }
	}

et là les résultats sont impressionnants puisqu'on a divisé par 1000 les temps d'exécution :

Code :

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

1
2
3
4
5
Avg time for 1 loop: 67102,74 ns and 2 loops: 196,03 ns
Avg time for 1 loop: 66433,83 ns and 2 loops: 107,84 ns
Avg time for 1 loop: 65604,50 ns and 2 loops: 70,45 ns
Avg time for 1 loop: 65398,80 ns and 2 loops: 60,41 ns
Avg time for 1 loop: 65668,16 ns and 2 loops: 62,58 ns

Finalement en alliant les deux méthodes on obtient :

Code :

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

1
2
3
4
5
Avg time for 1 loop: 1068892,18 ns and 2 loops: 133,53 ns
Avg time for 1 loop: 1617666,30 ns and 2 loops: 113,57 ns
Avg time for 1 loop: 1678028,28 ns and 2 loops: 106,40 ns
Avg time for 1 loop: 1566727,28 ns and 2 loops: 105,95 ns
Avg time for 1 loop: 1558759,11 ns and 2 loops: 111,07 ns

Soit un temps d'exécution divisé par 1000

[amira]

Moi j'ai des gains semblables, et en fait je trouve pas déconnant sur les machines modernes qu'un for ait été organisé de sorte d'être moins cher qu'une division entière.
...

En effet la technique semble pas mal mais après c'est un équilibre à trouver entre du code clair mais lent ou du code "obscur" mais rapide, cependant dans certains cas c'est quasiment indispensable et cela prouve surtout que des techniques simples et en remaniant son code cela vaut largement largement la peine.

[thelvin]

En effet moi non plus je n'obtiens pas les mêmes temps, même si dans le fond ça reste quand même pas négligeable puisque je divise par trois :

Ouais mais le truc que tu divises par trois est déjà négligeable, donc un gain dessus sera négligeable aussi. Pour que ce soit pas négligeable on cherche une situation où on fait un travail utile qui ne sera pas énormément plus cher qu'une division entière. Pas courant.

Sinon il y a une autre astuce qui marche très bien lorsqu'on utilise des String dans une boucle "for" c'est d'utiliser des "StringBuilder".

Oui mais ça c'est connu, c'est pas vraiment une astuce. Quand on concatène beaucoup, genre en boucle, on utilise StringBuilder, pas l'opérateur + . C'est une question de savoir ce qu'il faut faire, pas de connaître des astuces.
C'est la raison principale de l'existence de StringBuilder.

[adiGuba]

Salut,

Je souhaiterais savoir si vous avez des astuces pour améliorer votre code java.

La principale astuce : faire un code propre sans chercher à l'optimiser.
La seconde astuce : laisse la JVM faire cela, elle le fait très bien !

C'est contre-productif de chercher à optimiser à tout prix. Non seulement cela te prendra beaucoup plus de temps à développez, mais cela ne garantie pas forcément un meilleur fonctionnement !
Tu peux avoir un résultat inverse dans un "vrai" code avec du "vrai" traitement, simplement parce que ton "optimisation" peut empêcher la JVM d'optimiser une autre partie du code nettement plus critique !



Avant de chercher à optimiser ton code, c'est con à dire mais il faut déjà que tu ai un problème de performance bien ciblé.
Sinon cela ne sert à rien !!!


Une fois le problème ciblé, tu peux alors étudiés les solutions qui s'offre à toi :
- Revoir le types des objets utilisés.
- Revoir les algorithmes.
- Mettre en places des caches.
- ...


Si tu as un code propre ce devrait être facile à faire.
Maintenant si tu as cherché toutes les petites astuces possibles pour "optimiser" ton code, tu risques d'avoir nettement plus de mal à "corriger" cela !!!

Et en général, j'ai remarqué que lorsqu'on tente d'optimiser son code à l'avance, on tombe dans des travers qui font qu'au final cela ne tournera pas forcément mieux... voir même pire !!!

Bon, sinon, voici une petite astuce à moi :

- String.split(String) est connu, simple et pratique...

Mais pas forcément efficace. Son paramètre est une expression de regex, String donc non compilée. Si on cherche à parser par exemple un gigantesque fichier CSV de structure simple, où toutes les lignes ont le même séparateur et que c'est un simple caractère trivial, appeler split() sur toutes les lignes va recompiler la même regex sur toutes les lignes et refaire la même analyse ultra-générale pour un pauvre caractère.
Implémenter la même chose en deux minutes à base de indexOf() et de substring() est sensiblement plus rapide.

Remarque : ceci n'est pas toujours vrai !!!

En effet si tu fait un split() sur un seul caractère "standard", ou sur un caractère spécial des regexp précédé par un antislash, la méthode split() n'utilise pas les regexp mais une implémentation basé sur les indexOf()

Bref : sur un Java récent (je ne sais plus quand cela a été mis en place), tu t'es embêté pour pas grand chose au final

Sinon il y a une autre astuce qui marche très bien lorsqu'on utilise des String dans une boucle "for" c'est d'utiliser des "StringBuilder".

Là plus qu'une optimisation c'est surtout une mauvaise utilisation des objets qui est en jeu. L'objet String ne doit pas être utilisé pour créer des chaines complexes !



a++

[thelvin]

Remarque : ceci n'est pas toujours vrai !!!

En effet si tu fait un split() sur un seul caractère "standard", ou sur un caractère spécial des regexp précédé par un antislash, la méthode split() n'utilise pas les regexp mais une implémentation basé sur les indexOf()

Bref : sur un Java récent (je ne sais plus quand cela a été mis en place), tu t'es embêté pour pas grand chose au final

Ah tiens oui. Bon, ce n'était pas sur du Java 6 ni 7, mais j'avais vérifié à l'époque, il se basait toujours sur les regexp et une analyse très générale.

... Bon, de nos jours, il reste qu'il ne connaît pas la taille exacte du tableau à renvoyer et donc qu'il va jouer au redimensionnement et à l'export dans un tableau final. Ce qui coûte cher pour rien.

... Mais en testant je me rends compte qu'aujourd'hui je ne gagne pas tant que ça, à cause du changement de substring(), qui construit toujours un nouveau char[] dupliqué, au lieu de pointer vers celui de la String appelée. Ce qui coûte cher aussi. Ça marche mieux si j'évite substring et que je stocke des paires d'indices de début et fin à la place. Mais ça devient vraiment compliqué, il faut vraiment avoir identifié ça comme un point chaud avec un profiler.

[adiGuba]

Ah tiens oui. Bon, ce n'était pas sur du Java 6 ni 7, mais j'avais vérifié à l'époque, il se basait toujours sur les regexp et une analyse très générale.

Oui c'est assez récent (et méconnu).

... Bon, de nos jours, il reste qu'il ne connaît pas la taille exacte du tableau à renvoyer et donc qu'il va jouer au redimensionnement et à l'export dans un tableau final. Ce qui coûte cher pour rien.

Si tu connais le nombre d'élément, tu peux toujours utiliser split(String,int).
Par contre je ne sais pas s'il utilise l'info pour optimiser l'allocation...


a++

[tchize_]

En effet moi non plus je n'obtiens pas les mêmes temps, même si dans le fond ça reste quand même pas négligeable puisque je divise par trois :

Et moi, puisque ton code ne fait strictement rien, je peux l'optimiser comme ceci:

Code :

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

1
2
3
4
5
6
public static long testSansLoop(int n, int m) {
    long start = System.nanoTime();
    counter +=n;
    counter2 +=n/m;
    return System.nanoTime() - start;
}

ce qui donne encore plus vite et sans boucle. On n'optimise pas une théorie de boucle, on optimise un problème concret. Optimiser pour le plaisir de gagner 2 nano secondes sur un code, c'est du n'importe quoi. Quand on optimise, c'est qu'on a déjà identifié
1) que l'application ou la méthode concernée n'a pas les performance voulue
2) le ou les chemins coupable qu'il va falloir optimiser

A ce moment là, on regarde, on analyse et, crois moi, c'est jamais sur des détails genre utiliser un + plutot qu'un modulo qu'on gagne. C'est souvent sur "trop de requetes inutiles à la DB", "trop d'appel au rafraichissement d'écran", "trop de transferts de données"

Et pour ça on a des outils magnifique: les profilers.

Pour le reste, fait du code propre, lisible, réutilisable et suivant les recommandations d'oracle et tout ira bien Il est fini le temps où le programmeur pouvait facilement déterminer les implications de vitesse de son choix de code. Entre le compilateur JIT de la JVM, le CPU qui réorganise les instructions, la mémoire dont la vitesse d'accès est aléatoire et l'OS qui peux endormir ton process n'importe quand, plus rien n'est prévisible.

[adiGuba]

Et moi, puisque ton code ne fait strictement rien, je peux l'optimiser comme ceci:

Code :

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

1
2
3
4
5
6
public static long testSansLoop(int n, int m) {
    long start = System.nanoTime();
    counter +=n;
    counter2 +=n/m;
    return System.nanoTime() - start;
}

Je pense qu'on ne pourra pas faire mieux :

Code :

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

1
2
3
4
5
Avg time for 1 loop: 4,84 ns and 2 loops: 0,62 ns and tchize_: 0,00 ns
Avg time for 1 loop: 4,14 ns and 2 loops: 0,32 ns and tchize_: 0,00 ns
Avg time for 1 loop: 4,14 ns and 2 loops: 0,21 ns and tchize_: 0,00 ns
Avg time for 1 loop: 4,15 ns and 2 loops: 0,22 ns and tchize_: 0,00 ns
Avg time for 1 loop: 4,15 ns and 2 loops: 0,21 ns and tchize_: 0,00 ns

a++