Discussion :

[bouliz]

Bonjour à tous.

Je dois dans le cadre de mon travail réaliser une doc sur les normes de développement JAVA. Celle-ci doit traiter entre autres des conventions de nomenclatures, formatage du code, bonnes pratiques de programmations, etc.

Je rédige actuellement une partie sur les bonnes pratiques liées à la performance. J'ai abordé les sujets suivants :

Utilisation des String (dans quel cas utiliser Stringbuffer plutôt que stringbuilder)
Utilisation des collections (dans quel cas utiliser telle ou telle implémentation)
Utilisation de Integer.valueOf plutôt que new Integer

Auriez vous des idées à me soumettre en vrac sur les bonnes pratiques liées à la performance?

Merci d'avance.

[tchize_]

Eviter les méthode synchronized (donc éviter StringBuffer) si ce n'est pas intéressant, surtout dans les environnement multi-CPU ou le synchronized a un surcoût.
Utiliser des méthodes "final" (attention c'est moche) ou "private" (même effet) pour les méthodes critique: Diminue la durée de branchement car calcul fait à la compilation (early binding)
Comme toujours, éviter les boucles inutiles, faire attention aux algos
Regarder la javadoc, pour beaucoup de classes utilitaire, java explique l'algo et son temps de calcul.
Eviter la création inutile d'objet (comme tu le mentionne avec integer, mais pour toutes les autres jouyeuseté assimilées)

[JHelp]

Bonjour,
Ne pas oublié de mettre à null une reference devenue inutile (pour aider le garbage collector). Faire des méthodes de destructions. (Toujours pour le garbage collector)
Un petit exemple :

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
 
public void myMethod()
{
      MyClass oneInstance;
      //
      //Construction de oneInstance, par exemple :
      oneInstance = new MyClass();
      //
      // Faire quelque chose
      // ....
      //
      //Detruit la réfance pour aider le gabage collector
      oneInstance.freeRam();
      oneInstance = null;
}

Et mettre dans la méthode freeRam toutes les variables de la classes à null (en détruisant proprement les instances)

En procédant on gagne en performance car le garbage collector à moins de travail à faire pour déterminer qui il doit détruire. Il fera sont travail par petits bout au lieu de tout faire d'un block quand la mémoire viens à manquer. De plus on évite pas mal de outOfMemory et une consommation de la mémoire vive inutile.

JHelp

[tchize_]

JHelp: ce que tu dit est vrai dans un jme, où l'implémentation du garbage collector est soumise à des contraintes spécifique qui l'empêche d'être aussi bon pour l'analyse de la heap. Le fonctionnement du garbage collector est assez complexe, mais coder une methode "nettoyage" dans un objet s'avère complexe au point de vue du code (faut rajouter la méthode, s'arranger qu'elle appelle la méthode sur les autres aobjets etc, jouer avec du type casting). De plus, si tu veux appeler freeRam() au 'bon moment' , tu dois faire un comptage de tes instance et c'est justement ce qu'on veux éviter avec le garbage collector.

Par contre, çà coute rien de libérer une grosse variable locale dès qu'on en a plus besoin.

Ex: t'as une liste de 500000 éléments, tu a besoin, dans une boucle, de faire une liste dérivée, çà paie pas de mine de faire un =null avant de faire le new suivant (la mémoire occupé par la précédent sera "libérable" avant de faire le new, tandis que si tu fais x = new MonGrosX(), je pense qu'il n'est libérable qu'après l'assignation.

[gifffftane]

En Java, à mon humble avis, la meilleure solution serait de laisser ce chapitre vide.

La plate-forme se débrouille très bien pour les optimisations courantes, sans la moindre intervention du programmeur.

Après, on peut faire intervenir le contexte propre de l'appli.

Effectivement, une des bases serait de distinguer si on est en Java Me ou JRE ! Si on applique les règles d'optimisation d'un environnement Java Me à un environnement JRE... on arrivera évidemment à l'inverse de ce que l'on veut obtenir.

Donc, peut être, juste un mot dans ce chapitre : Réfléchissez.

[tchize_]

D'accord avec toi, cependant, préciser aux lecteur que les méthode synchronized on un surcout et rappeler que, par définition, elles sont un goulot d'étranglement en multi threading, c'est pas du luxe

Après tout, c'est pas pour rien que java 5 a introduit stringbuilder, les perfs de stringbuffer étaient catastrophiques sur les multi core. Et toujour du bon sens dans l'utilisation des apis de sun, me souviens avoir du intervenir dans un code "lent", tout çà pour me rendre compte que, à chaque "touche du clavier appuyée", il y avait une requête réseau qui sérialisait un bon 50.000 communes avec leur codes postaux et le désérialisait de l'autre coté. Donc voilà, en général, un peu de bon sens

Sinon, les profilers, çà aide ^^, car dans un environnement objet, on ne vois pas toujours directement les conséquence d'une mauvvaise utilisation d'un objet