Codage performant, des liens ?

Bonjour.

Je n'ai rien trouvé à ce sujet dans la FAQ. Connaissez-vous des liens
donnant des conseils sur les principes fondamentaux pour obtenir un
code plus rapide (par exemple, utiliser des StringBuffer plutôt que
des String, etc.) ?

Merci beaucoup.

Bonjour,

Pas de lien en tête mais voici mes habitudes perso :

- Privilégier la réutilisation d'objets existants (référence) par
rapport à la creation de nouveaux (new) : new à un coup trés souvent
plus élevé qu'une RaZ de l'objet ! Les pools d'objets peuvent ici
présenter une alternative à évaluer.
- Privilégier les équivalent non-"thread-safe" si pas de multithread
nécessaire dans le bloc & pour les éléments visés :
-> StringBuilder au lieu de StringBuffer
-> ArrayList au lieu de Vector (un grand classique)
-> ...
- marquer final sur les methodes, références (param, variables) dès que
possible (facilite le travail d'un JIT)
- poser des références locales final dans une méthode si le champ est
trés utilisé (évite les problème en multithread, car c'est toujours la
même instance qui sera utilisée dans la méthode/bloc et assure au JIT
que la référence ne peut changer)

Enfin, une optimisation "aprés coup" à l'aide d'un outil d'analyse
adequat (analyse des points chaud et des créations/destructions
d'objets) est toujours efficace.

Si vous avez d'autres recomandations ou même des commentaires sur ces
habitudes, n'hésitez pas à poster à la suite du fil ...

A+
TM

Si vous avez d'autres recomandations ou même des commentaires sur ces
habitudes, n'hésitez pas à poster à la suite du fil ...

À mon avis, toutes ces bidouilles ne valent pas grand chose par rapport
à une réflexion sur les algorithmes: il n'y a que là que tu gagneras
vraiment en performance.

--
PG

Si vous avez d'autres recomandations ou même des commentaires sur ces
habitudes, n'hésitez pas à poster à la suite du fil ...

À mon avis, toutes ces bidouilles ne valent pas grand chose par rapport
à une réflexion sur les algorithmes: il n'y a que là que tu gagneras
vraiment en performance.

Algorithmes ? Pas si sûr. Il a été démontré depuis assez longtemps
qu'avec un JIT un algorithme récursif peut être quif quif avec un
itératif ... une bonne compréhension des techniques d'optimisation du
JIT est capitale selon moi pour produire du code qui ne sera pas
"optimisé en théorie" mais "optimisé en pratique".

En plus des voies dont je parlais, je pencherai plutôt ver le choix de
conception utilisant les patrons adequat facilitant la réutilisation ...
mais cacun son choix ;-)

A+
TM

Patrick wrote:

Si vous avez d'autres recomandations ou même des commentaires sur ces
habitudes, n'hésitez pas à poster à la suite du fil ...

À mon avis, toutes ces bidouilles ne valent pas grand chose par rapport
à une réflexion sur les algorithmes: il n'y a que là que tu gagneras
vraiment en performance.

+1

Eviter de créer des objets ou mettre un object final ne fait pas gagner
de temps (ou 0.1%).

La plupart du temp le point faible est le logging ou la base de données.
Pour le StringBuffer seulement dans une loupe (pas pour concaténer 3
Strings). BufferedReder et BufferedWriter peuvent aider aussi.

Pour optimiser, la meilleur solution est le profiler. Je me sers de
http://profiler.netbeans.org

puis il y a
http://www.javaperformancetuning.com/resources.shtml

Anthony
--
Comme il disent en Anglais 'pre-emptive optimization is the root of all
evil'.

Patrick wrote:

Si vous avez d'autres recomandations ou même des commentaires sur ces
habitudes, n'hésitez pas à poster à la suite du fil ...

À mon avis, toutes ces bidouilles ne valent pas grand chose par
rapport à une réflexion sur les algorithmes: il n'y a que là que tu
gagneras vraiment en performance.

+1

Eviter de créer des objets ou mettre un object final ne fait pas gagner
de temps (ou 0.1%).

Tout dépend de l'algo ...

La plupart du temp le point faible est le logging ou la base de données.
Pour le StringBuffer seulement dans une loupe (pas pour concaténer 3
Strings).

La "concaténation" est justement gérée par un StringBuffer (ou plus
précisement maintenant par un StringBuilder).

Ainsi pour :
String str ="123";
str = str + "456" + "789";
On obtien de compilé :
String str = "123";
str = (new
StringBuilder()).append(str).append("456").append("789").toString();

BufferedReder et BufferedWriter peuvent aider aussi.


Pour optimiser, la meilleur solution est le profiler. Je me sers de
http://profiler.netbeans.org

+1 !

puis il y a
http://www.javaperformancetuning.com/resources.shtml

J'aimais bien
ftp://ftp.glenmccl.com/pub/free/jperf.pdf
mais je me rends compte qu'avec tout les changements intervenus dans
HotSpot et la plateforme, il serait certainement trés interessant d'en
faire une MàJ....

Anthony
--
Comme il disent en Anglais 'pre-emptive optimization is the root of all
evil'.

Citation rime toujours avec précision :P
"We should forget about small efficiencies, say about 97% of the time:
premature optimization is the root of all evil" (Tony Hoare)

A+
TM

On Fri, 27 Oct 2006 11:59:30 +0200, TestMan <none@example.com> wrote:

- Privilégier les équivalent non-"thread-safe" si pas de multithread
nécessaire dans le bloc & pour les éléments visés :
-> StringBuilder au lieu de StringBuffer
-> ArrayList au lieu de Vector (un grand classique)
-> ...
- marquer final sur les methodes, références (param, variables) dès que
possible (facilite le travail d'un JIT)

Je savais bien que j'avais vu un truc à se sujet :
http://www-128.ibm.com/developerworks/java/library/j-jtp04223.html

Ca serait pas si utile que ça de marquer les méthodes final
finalement. Et la synchronisation n'est somme toute si couteuse qu'on
le croit.

On Fri, 27 Oct 2006 11:59:30 +0200, TestMan <none@example.com> wrote:

- Privilégier les équivalent non-"thread-safe" si pas de multithread
nécessaire dans le bloc & pour les éléments visés :
-> StringBuilder au lieu de StringBuffer
-> ArrayList au lieu de Vector (un grand classique)
-> ...
- marquer final sur les methodes, références (param, variables) dès que
possible (facilite le travail d'un JIT)

Je savais bien que j'avais vu un truc à se sujet :
http://www-128.ibm.com/developerworks/java/library/j-jtp04223.html

Ca serait pas si utile que ça de marquer les méthodes final
finalement. Et la synchronisation n'est somme toute si couteuse qu'on
le croit.

Concernant final, faciliter le travail de quelqu'un ne veut pas dire
qu'il puisse aller forcement plus vite à tous les coup ou quelque soit
les conditions.

Et dans le cas précis, je doute qu'un micro banc de test puisse
démontrer quoi que ce soit (dans un sens comme dans l'autre). Car en
condition d'appel, la "chaleur" des points d'appel sera
vraisemblablement identique (et donc le niveau d'optimisation apploqué
égal). Or si les bytecode sont les mêmes, les assembleurs injectés le
seront aussi.

Pour vraiment savoir si final possède un effet en terme de performance
avec les JIT récents, il faudrait plutôt tester celà sur une grosse
application (style un serveur d'appli).

Je serait surpris si par exemple en utilisant final sur les références
on obtient rien ...

A+
TM

On Thu, 02 Nov 2006 10:11:49 +0100, TestMan <none@example.com> wrote:

Et dans le cas précis, je doute qu'un micro banc de test puisse
démontrer quoi que ce soit (dans un sens comme dans l'autre). Car en
condition d'appel, la "chaleur" des points d'appel sera
vraisemblablement identique (et donc le niveau d'optimisation apploqué
égal). Or si les bytecode sont les mêmes, les assembleurs injectés le
seront aussi.

Si ça génère le même code une fois optimisé, c'est que ça n'a aucun
effet. Si le bout de code n'est pas optimisé, c'est que ce n'est pas
un point chaud, donc qu'il n'a aucun effet sur les perfs. C'est aussi
l'intéret d'un micro-benchmark : il chauffe le code pour être sur
qu'il est intéressant.

Pour vraiment savoir si final possède un effet en terme de performance
avec les JIT récents, il faudrait plutôt tester celà sur une grosse
application (style un serveur d'appli).

Sur un serveur d'appli, ce que je decrit précédement sera encore plus
valable. Le bout de code pas optimisé provoquera un bruit si faible
qu'il sera inférieur à l'incertitude de mesure.

Je serait surpris si par exemple en utilisant final sur les références
on obtient rien ...

A+
TM