Discussion :

[Ricky81]

Bonjour,

Ibrahim MOUKOUOP NGUENA nous propose le premier volet d'une série d'articles sur l'écriture de programmes performants en Java :

Cet article est le premier d'une série de trois articles consacrés à la performance des applications java.
Il traite de considérations générales applicables au niveau de l'algorithmique et de la programmation.

• Ecrire des programmes performants en Java, partie 1 : considérations générales
• Ecrire des programmes performants en Java, partie 2 : architectures n-tiers et bases de données
• Ecrire des programmes performants en Java, partie 3 : applications J2EE

Vos avis et remarques sont les bienvenus.

[dingoth]

Bonjour,


Je comprends le besoin de cet article pour pas mal de développeurs qui ne se soucient pas trop de gérer les performances, mais qui ont des problèmes avec, mais cet article est, selon moi, trop succint et apporte des éléments réellement contreproductifs, tant pour l'efficacité que pour les performances.

Je pense essentiellement au fait de prôner l'utilisation des StringBuffer tout au long de l'article, alors que dans 90% des cas, un StringBuilder est plus utile, même s'il en est fait mention... une seule fois. Le terme StringBuffer apparaît 17 fois et dans plusieurs sections, le terme StringBuilder... 3 fois dans une seule section.

L'auteur parle en outre de la possibilité d'améliorer la vitesse d'exécution dans son item "IV-D-1-d", mais le fait d'utiliser un StringBuffer dans ce cas n'aide en rien la synchronisation dans un contexte multithread, contrairement à ce qu'il laisse penser quelques sections plus bas. Car les données internes du StringBuffer seront toujours consistantes en terme de méthode, mais certainement pas en terme d'utilisation globale de l'objet.

De plus, tout placer à null n'est pas toujours utile afin de gagner en performance. L'auteur oublie le contexte de l'intérêt de mettre à null, notamment lors de méthodes courtes.

Enfin, enfoncer le clou et vouloir "singletoniser" toute création d'objet est lui sujet à plus d'erreur. Tant qu'à choisir, je préfère avoir à gérer des performances plus faibles que me retrouver avec des problèmes de concurrence en permanence. Le coût de création d'un objet est toutefois généralement faible, même s'il n'est pas nul.

Même si les trois quarts de ces règles sont davantage du bon sens qu'autre chose, je suis extrêmement perplexe vis-à-vis de cet article, et je crois que je vais m'en éloigner fissa.

[pomauguet]

Pareil, je trouve que l'article propose des solutions qui vont à l'encontre d'une bonne conception.

Dire qu'il faut toujours faire un constructeur par défaut, puis faire des set sur tous les champs, puis une méthode init est une mauvaise idée. A quoi sert de faire de l'objet dans ces conditions?
Un constructeur sert avant tout à contraindre (et paradoxalement, pas à réserver en mémoire, car cela est fait par new).
C'est à dire je veux forcer que pour créer une instance de Point, j'impose aux utilisateurs de ma classe de me donner une abcisse et une ordonnée.
La méthode proposée, permet de faire un point sans argument, ce qui est sémantiquement faux.

Par contre, il est tout à fait vrai qu'il faut au maximum minimiser le nombre d'instanciation, car c'est ce qui est le plus coûteux en temps. Mais il ne faut pas non plus sacrifier une bonne conception sur l'autel de la performance... (car la bonne conception aide à la maintenabilité).

La partie sur l'Exception est très mal écrite. Si l'attribut badValue est un attribut de la classe, il est instancié lors du constructeur de l'objet qui contient la méthode testValue, ce qui est un peu à l'opposé de la philosophie de l'auteur. Il manque les parenthèses pour la méthode testValue.
De plus, minimiser la création d'instance pour le cas des exceptions me paraît un peu dérisoire. Car en cas d'exception, il y a de grandes chance que le traitement s'arrête, et donc on est pas à la milliseconde près.

[pseudocode]

Petites remarques en vrac:

Concernant la réutilisation des objets en les definissant comme variable d'instance :

- Bonne pratique : Les variables d'instances d'une classe représentent soit une composition (= définissent une relation), soit un attribut (= définissent l'état). Ce n'est pas censé être l'équivalent du tas (heap) d'un programme C.

- Implémentation : Attention car cette approche n'est pas thread-safe ! Si deux threads utilisent le meme objet, les modifications sur les valeurs de cet objet risquent de se télescoper.


Concernant l'utilisation des StringBuffer :

- Implémentation : Cette classe est thread-safe. Pour se faire, elle utilise la synchronisation Java sur toutes les methodes append(), ce qui est extrêmement couteux. Dans le cas d'une utilisation mono-thread (c'est généralement le cas), il est préférable d'utiliser la classe StringBuilder.

[tomtomJ]

Hello,

Mêmes remarques que les précédentes: la plupart de ces optimisations sont soit du bon sens, soit n'en sont pas vraiment. Le plus grave est qu'elles vont souvent à l'encontre d'une bonne conception.
En particulier, ça fait belle lurette que les créations d'objets ne coûtent plus cher car la JVM sait réutiliser les instances comme il faut, et de fait les pools d'objets ont davantage tendance à baisser les performances qu'à les améliorer.
Bref, cet article me fait plutôt penser à une pub pour son framework que de vrais conseils pertinents.

[xtope]

cet article me fait plutôt penser à une pub pour son framework que de vrais conseils pertinents.

Pas sympa de dénigrer ainsi l'auteur qui a au moins pris le temps d'écrire cet article...

Cela dit, je suis d'accord sur le fait qu'il faut revoir certaines choses.
Je rajoute une couche à ce qui a été dit : dans les structures des données, je vois des objets comme Vector... aie.

Mais pour un débutant comme moi je trouve qu'il y a quand même des choses intéressantes à savoir.