Discussion :

[womannosky]

Bonjour à tous,
Je suis à la recherche de tous les trucs et astuces pour améliorer le code en Java sur tous les sujets possibles pour une vitesse d'éxecution encore plus rapide.
EX : La boucle for est plus rapide en décrémentant le compteur plutot qu'en l'incrémentant...


Merci pour vos suggestions !

P.S : Je suis preneur de sites internets si vous avez des liens ;-)

[CyberChouan]

Si tu veux vraiment apprendre à écrire un code optimisé, tu devrais te tourner vers un livre de type "Bonnes pratiques en java": il existe des pavés entiers sur le sujet de l'optimisation. Pour compléter tes exemples:
- utiliser des StringBuffer ou StringBuilder pour concaténer des chaînes
- utiliser des pools pour gérer les Thread et les connexions à la base
- etc.

[adiGuba]

Salut,


Les deux premières règles de l'optimisation d'un programme :

1. Ne pas le faire.
2. (Pour les experts seulement!) : Ne pas le faire encore.

cela veut dire qu'avant d'optimiser un code il faut avoir bien cibler l'origine du problème...


La plupart des astuces d'optimisation (comme inverser une boucle for) ne font que rendre le code moins lisible et potentiellement plus problématique sur le long terme.



a++

[womannosky]

Je suis potentiellement d'accord, celà rend surement le code moins lisible. Néanmoins, dans certains cas, notamment lors de calculs conséquents, on aurait bien besoin d'optimiser certaines choses comme un algo par exemple.
De toute façon, l'optimisation d'un programme se fait en général à la fin, lorsque tout marche, donc les problèmes sur le long terme, je m'en préoccupe pas trop, surtout que je connais bien mon programme.

Alors si vous avez des idées, des suggestions... Merci à vous !

[jojodu31]

je suis assez d'accord avec adiGuba, et avec toi aussi : comme tu le dis l'optimisation sera largement plus efficace au niveau algo plutot que programmation selon moi ...

[womannosky]

comme tu le dis l'optimisation sera largement plus efficace au niveau algo plutot que programmation selon moi ...

Il faut dire que c'est assez spécifique au Java, non ? ou au langage objets en général ?
Peut être que l'optimisation d'un code est plus performant et intéressant pour une programmation séquentielle (en C par exemple).

[adiGuba]

Néanmoins, dans certains cas, notamment lors de calculs conséquents, on aurait bien besoin d'optimiser certaines choses comme un algo par exemple.

Donc ta question est mal posé !

Au lieu de te dire "comment optimiser ?", il faudrait te dire : "après avoir profiler mon application, j'ai détecter la source des mauvaises performances. Voici le code et comment l'optimiser ?"


Personnellement, je pense qu'utiliser un parcours inverser est une mauvaise pratique, et qu'il est préférable d'utiliser un Iterator ou le for étendus...

a++

[womannosky]

Ma question était mal posée d'accord, si tu veux.
Je n'ai pas de code spécifique, je voulais juste vous entendre sur des choses générales et non bien spécifiques à un problème (des choses réutilisables sans cesse).

Je souhaiterais voir ce genre de choses :

Personnellement, je pense qu'utiliser un parcours inverser est une mauvaise pratique, et qu'il est préférable d'utiliser un Iterator ou le for étendus...

Merci.

[®om]

Je pense aussi que ce n'est pas une bonne chose à faire, mais que c'est une bonne chose à savoir (rien que par curiosité).

Par curiosité, justement, pourquoi une boucle for avec un indice qui décrémente est-elle plus rapide? Au niveau instruction, il existe aussi bien un «incrémenteur de 1» qu'un «décrémenteur de 1», non?

[_skip]

Quand j'ai commencé l'assembleur, on me disait de remplacer des sub 10 par des add -10. Ce genre de chose est un peu de l'esbroufe pour intellectuels car dans la pratique, on se retrouve surtout avec des algos moins lisibles qui vous font gagner 50ms sur 15 minutes de traitement.

Je pense que les gains ne sont pas sur des choses comme décrémenter un compteur au lieu de l'incrémenter, ou éviter un appel à une méthode en faisant du inlining. Sauf exception (algorithme de compression appelé plusieurs milliards de fois), les véritables gains sont au niveau conceptuel: utilisation des bonnes structures de données appropriées aux situations (tableau/listes/arbres/hashmap), efficacité du schéma de la base de donnée.... Etc...

[boromir73]

Par curiosité, j'ai utilisé ASM pour pour visualiser le bytecode généré à partir de boucles for avec incrémentation et décrémentation.

Incrémentation : IINC 1 1

Décrémentation : IINC 1 -1

En revanche il y a une différence au niveau du test d'arrêt : 2 instructions pour comparer à une constante, 1 seule instruction pour comparer à 0.

Néanmoins, je n'ai pas réussi à mesurer une différence de vitesse à l'exécution.

[womannosky]

Par curiosité, justement, pourquoi une boucle for avec un indice qui décrémente est-elle plus rapide? Au niveau instruction, il existe aussi bien un «incrémenteur de 1» qu'un «décrémenteur de 1», non?

Notamment, je crois que c'est plus rapide car tu fais ton test de comparaison par rapport à 0 dans certains cas, aulieu de comparer ta variable qui s'incrémente par rapport à 10 par exemple.

Sinon, je suis d'accord avec vous, le concept est essentiel, mais il ne faut pas me faire croire que dans certain cas, même en ayant un modèle de conception nickel, on n'est pas besoin d'optimiser un algorithme. On ne travaille pas tous avec 4 processeurs.

Ma question portait sur les expériences et tests que vous auriez éventuellement pu faire et montrant par exemple, qu'un test est plus performant qu'un autre.

[®om]

Ah oui, merci à vous deux, effectivement ça fait gagner 1 instruction pour la condition d'arrêt…

À ne jamais utiliser évidemment, les langages de haut niveau sont là pour ne pas se soucier de préoccupations de bas niveau (sinon on programmerait en bas niveau)…

[adiGuba]

Par curiosité, justement, pourquoi une boucle for avec un indice qui décrémente est-elle plus rapide? Au niveau instruction, il existe aussi bien un «incrémenteur de 1» qu'un «décrémenteur de 1», non?

C'est surtout soit-disant plus rapide parce qu'on accède qu'une fois à la taille du tableau et non pas à chaque itération. C'était peut-être vrai à l'époque de Java 1.0 mais maintenant c'est clairement inutile tant la différence est minime et ne doit se faire sentir que sur des tableaux de taille vraiment astronomique...



En fait on peut faire tout aussi bien en déclarant une variable locale juste avant le for indexé :

Code :

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

1
2
final int length = array.length;
for (int i=0; i<length; i++) {

Optimiser un code, cela peut paraitre cool, mais dans bien des cas cela ne fera que rendre le code illisible. A vouloir optimiser pour optimiser on se retrouve vite avec un code illisible et pas forcément plus performant. Pire même, on peut avoir des soit-disans optimisations qui empêche le compilateur/JVM de faire leurs propres optimisations




Il y a nettement plus d'intérêt à passer ce temps là sur la lisibilité du code, car mis à part quelques antipatterns, dans la plupart des cas la différence ne sera pas flagrante.

L'avantage c'est qu'en cas de mauvaise performance, avec un code propre et net on peut facilement trouver l'origine du problème et envisager des changements.


La plupart du temps des optimisations prématuré amène a de mauvais choix et à des problèmes de performances encore pire...

Sinon, je suis d'accord avec vous, le concept est essentiel, mais il ne faut pas me faire croire que dans certain cas, même en ayant un modèle de conception nickel, on n'est pas besoin d'optimiser un algorithme. On ne travaille pas tous avec 4 processeurs.

Personne n'a dit cela, mais il est inutile de vouloir chercher à optimiser à tout prix s'il n'y a pas de problème...

Ma question portait sur les expériences et tests que vous auriez éventuellement pu faire et montrant par exemple, qu'un test est plus performant qu'un autre.

Un exemple : ta boucle inversé (ou une boucle sur un index tout court d'ailleurs) est une véritable catastrophe lorsqu'elle est utilisé sur une LinkedList...

La boucle for étendu propose dans 99% des cas la meilleure solution



a++

[®om]

En fait on peut faire tout aussi bien en déclarant une variable locale juste avant le for indexé :

Code :

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

1
2
final int length = array.length;
for (int i=0; i<length; i++) {

ou

Code :

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

for(int i = 0, len = array.length; i < len, i++)

Mais bien sûr, la boucle foreach est mieux

[womannosky]

Je crois avoir compris, le Java n'est pas un langage où l'optimisation est flagrante et dans ce cas, je retire ma question.
J'espère juste que celà est dit sincèrement et non par "prônage" de ce langage (je suppose que tout n'est pas parfait quand même )

En tout cas, merci à tous pour vos suggestions !

[adiGuba]

Je crois avoir compris, le Java n'est pas un langage où l'optimisation est flagrante et dans ce cas, je retire ma question.
J'espère juste que celà est dit sincèrement et non par "prônage" de ce langage (je suppose que tout n'est pas parfait quand même )

Ce n'est pas propre à Java !

Dans tout développement une optimisation prématuré n'est pas de bon augure...


a++

[womannosky]

Ce n'est pas propre à Java !
Dans tout développement une optimisation prématuré n'est pas de bon augure...

Ca, j'ai bien compris.
C'est juste qu'on s'y préoccupe plus en C ou en C++ par exemple. C'est ce que je voulais dire.

[_skip]

On s'y préoccupe plus en C *quand on fait de l'algo* c'est vrai. Il faut pas oublier qu'une tonne de ces bonnes pratiques qu'on trouvent sur le net pour optimiser du code datent de l'époque ou 64ko de ram c'était encore beaucoup.

[adiGuba]

C'est juste qu'on s'y préoccupe plus en C ou en C++ par exemple. C'est ce que je voulais dire.

Pas forcément...
La grosse différence pour moi c'est la gestion de la mémoire (vive le GC !).

Pour le reste les optimisations en C/C++ peuvent être encore pire (une code avec des opérations sur des pointeurs peut vite devenir incompréhensible )


a++