[Optimisation][Infos] Détails techniques

Bonjour,

je travaille actuellement au Vietnam dans une boite de développement Offshore.

Dans mon projet actuel, on bosse sur des projets J2EE. Avec ma petite équipe, je suis souvent confronté à des lignes de programmation comme celles-ci:

Code:

---

1 2 3 4 5 6 7 8

for(in i = 0; i < maListe.size(); i++) { MaClasse monObjet = (MaClasse) maListe.get(i); String attribut1 = monObjet.getAttribut1(); ... if (<un certaine condition de sortie>) return; }

---

De quoi je me plaints : Déclaration de variable dans une boucle, return brutal. En cours d'algo, on nous a tellement martelé le cerveau sur les notions d'invariants de boucle et tout le toutim qui va avec. Et quand je vois ce genre de code, j'ai des sueurs froides

Ils me disent que ça tourne/ça marche. Moi je leur dis qu'au niveau algorithmique c'est quand même pas terrible. En fait, je poste un message pour demander aux experts des details techniques concernant l'exécution du code ci-dessous par la JVM. Pourquoi il n'est pas top. Ca me permettra de renforcer mon argumentation.

Merci

Bonjour,

Pour ma part, je ne vois aucun problème de déclarer des variables dans une boucle. Je dirai que c'est une bonne pratique vu que ces variables sont déclarées et visibles que dans le bloc où elles sont utilisées.

Et toi, comment aurais-tu codé cette boucle?

Absolument aucun pb dans ce code.

Ok, chippotons, je préfère mettre des acolades après un if et j'utiliserai la nouvelle boucle if de Java 5.0 (pas encore dispo dans la JEE).
:lol:

Outre les limitations techniques à certains languages (qui obligent par exemple à tout déclarer au début ou qui ne peuvent pas avoir de blocs dépassant une certaine taille ou dont les noms de variables sont limités à 5 lettres max), certains styles de prog sont (TRES - voir guerres de religions) fortement dépendants du lycéee/la fac/le livre/le site web, bref l'endroit où tu as appris à programmer, de qui t'as formé et/ou de l'endroit où tu bosses. Sans compter que le compilateur peut repasser derrère et optimiser tout ca sans que tu le sache.

La prog ca change et évolue avec le temps. Hum en fin de DESS les profs nous avaient fait marrer en nous listant les règles de programmation auquelles ils avaient eux eût droit au début des années 80... top marrant...

Sinon lire les bouqins sur Java et voir le site de Sun pour les recommendations de programmation en ce language.

Note perso : mais ouf quel plaisir en passant du C et du Pascal à C++ et à Java en envoyant tout ce genre de contraintes valser à la poubelle... Et en plus au final c'est bien plus lisible !

Citation:

---

Envoyé par sleepy2002

Bonjour,

je travaille actuellement au Vietnam dans une boite de développement Offshore.

Dans mon projet actuel, on bosse sur des projets J2EE. Avec ma petite équipe, je suis souvent confronté à des lignes de programmation comme celles-ci:

Code:

---

1 2 3 4 5 6 7 8

for(in i = 0; i < maListe.size(); i++) { MaClasse monObjet = (MaClasse) maListe.get(i); String attribut1 = monObjet.getAttribut1(); ... if (<un certaine condition de sortie>) return; }

---

De quoi je me plaints : Déclaration de variable dans une boucle, return brutal. En cours d'algo, on nous a tellement martelé le cerveau sur les notions d'invariants de boucle et tout le toutim qui va avec. Et quand je vois ce genre de code, j'ai des sueurs froides

Ils me disent que ça tourne/ça marche. Moi je leur dis qu'au niveau algorithmique c'est quand même pas terrible. En fait, je poste un message pour demander aux experts des details techniques concernant l'exécution du code ci-dessous par la JVM. Pourquoi il n'est pas top. Ca me permettra de renforcer mon argumentation.

Merci

---

Pour moi non plus, aucun probleme, les variables déclarées sont des références en plus de ça => aucun soucis a te faire au niveau des perf...

apres pour l utilisation des return, break, continue a chacun de voir :wink:

C'est vrai qu'un return brutal comme ca marche parfaitement mais c'est souvient mieux de faire un while (ou do while) avec un bon gardien de boucle.

Pour ce qui est des déclarations de variables dans la boucle, je pense que ca ne pose aucun problème vu que le compilateur arrangera tout ça pour lui.

Je ne vois aucun probleme dans ce type de code. Le fait de ne pas mettre de return "brutal" comme tu dis vient du langage procedural et pour moi ca ne pose aucun probleme dans la pratique.
Pour la declaration de variable, il est parfois obligatoire de le faire dans la boucle

Code:

---

1 2 3 4

for (int i=0;i<liste.size();i++) { Object obj = (Object)liste.get(i); //manipulation de l'objet qui oblige d'avoir une adresse differente de l'iteration precedente }

---

Pour ce qui est des accolades, à mon avis, ca aussi ca vient d'une habitude dans d'autres langages. En java, ça ne pose pas de probleme.

Pour mettre mon grain de sel:

La declaration dans la boucle est pas super sexy mais si ca se trouve le compilo la vire de la boucle pour optimizer de toute facon, si qqun a le courage de verifier.

Declarer une var dans une boucle c'est mal! Pourquoi ?

A chaque declaration d'une variable dans un bloc (typiquement le bloc de la boucle), la VM alloue la place pour la variable sur la pile. Avouez qu'on a tout de meme vu mieux au niveau optimization des ressources non ?

Par contre au niveau performances si c'est une grosse boucle ce serait bien aussi de faire:

Code:

---

1 2	int taille = maListe.size(); for (int i = 0; i < taille; i++)

---

Tant qu'on en est a chipoter, appeler un increment de boucle i meme si c'est tres repandu, c'est pas top. Pourquoi ? En cas de probleme une recherche sur i sera bcp moins efficace qu'une recherche sur index par exemple.. sans compter qu'en cas de boucles imbriquees, i, j, k, l ... bonjour la relecture avec un nom clair moins de risque de confusions.

Bulbo :wink:

Citation:

---

Envoyé par bulbo

Declarer une var dans une boucle c'est mal! Pourquoi ?

A chaque declaration d'une variable dans un bloc (typiquement le bloc de la boucle), la VM alloue la place pour la variable sur la pile. Avouez qu'on a tout de meme vu mieux au niveau optimization des ressources non ?

---

:?: :?: :?:

Peux-tu expliquer?

Dans l'exemple donné par sleepy2002, la VM alloue seulement une place dans la pile (stack) pour conserver la référence sur monObjet et non à chaque itération comme tu l'écris.

Citation:

---

Envoyé par jowo

Bonjour,

Pour ma part, je ne vois aucun problème de déclarer des variables dans une boucle. Je dirai que c'est une bonne pratique vu que ces variables sont déclarées et visibles que dans le bloc où elles sont utilisées.

Et toi, comment aurais-tu codé cette boucle?

---

Ben en fait je l'aurai fait de cette manière :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

MaClasse monObjet = null; String attribut1 = null; int i = 0; boolean pasDePb = true; while (i < maListe.size() && pasDePb) { monObjet = (MaClasse) maListe.get(i); attribut1 = monObjet.getAttribut1(); ... if (<condition de sortie> pasDePb = false;   i++; }

---

Vu qu'à chaque itération on n'utilise qu'un essemble unique de variables, je me disais qu'il était logique de les déclarer avant la boucle. Effectivement dans les cas où l'on a des boucles imriquées et que des variables ne sont utilisées que pour des cas précis dans la/les boucles, c'est pas mal de les déclarer au moment où l'on en a besoin.

Sinon merci pour vos détails technique, j'essaye d'avoir l'avis d'expert comme ça je peux réviser mon jugement :P.

Citation:

---

Envoyé par jowo

Dans l'exemple donné par sleepy2002, la VM alloue seulement une place dans la pile (stack) pour conserver la référence sur monObjet et non à chaque itération comme tu l'écris.

---

Au temps pour moi, je suis creve ce matin .. je devrais eviter les discussions techniques :oops:

Mais bon ca reste une bonne habitude de declarer tout ce que l'on peut avant une boucle ..

Par contre ce que j'ai dit est valable dans le cas de boucles imbriquees .. je me rattrape comme je peux :wink:

Bulbo :oops:

Oui MAIS justement comme il a été dit plus haut et ce grace aux divers optimisations des compilateurs modernes (pas que Java, ca marche aussi dans C++ et les autre languages également) tu n'as pas besoin (en général) de faire ce genre d'optimisations toi-même : le compilateur s'en charge pour toi.

Ok, ok ici c'était un exemple simple mais faire trop de choses de genre peut nuire à la lisibilité du code (et donc à ca réutilisation ou à sa maintenance par qqun d'autre). Qui plus est certaines optimisation personelles ont actuellement des effets contraires à ceux espérés soit directement dans le code (utilisation de la mauvaise variable à la mauvaise valeur), soit justement à cause des optimisations apportées ultérieurement par le compilateur.

Il y a 10~20 ans le moto c'était (entre autre) : réutilisez des variables pour éviter de gaspiller la mémoire.
Aujourd'hui le moto c'est : faîtes quelque chose de sécurisé* et de lisible et par pitié laissez le compilateur faire son boulot d'optimisations. Limitez la visibilité (les variables ne sortent pas des blocs) et surtout ne faîtes pas d'optimisations** de bouts de chandelles !

*en évitant de réutiliser les même variables pour des traitement différents ce qui peut ammener des erreur ou des pb.

** Sauf si vous vous appelez John Carmack et/ou que vous programmez en assembleur.

Bon évidement ca ne veux pas dire non-plus qu'il faut pour autant programmer comme un saguoin.

Edit - Hum faudrait'il faire a nouveau comme en C et définir toutes nos variables de parcours d'index bien gentiment tout en haut de notre méthode ? Egalement empiler des appels de methodes atomiques ca bouffe une mémoire monstreuses, revenons au code mono-bloc !

Salut,


Je suis en gros du même avis que bouye, mais il est toujours utile de connaitre le fonctionnement du compilateur et des ses optimisations/remplacements afin d'éviter certaines surprises...

L'exemple le plus frappant est l'utilisation de l'opérateur + entre deux String dans une boucle qui provoque de nombreuse allocation/desallocation inutile...

a++

Citation:

---

l'opérateur + entre deux String

---

Exact ca c'est quelque chose de tres important et ni la doc ni les livres n'insistent réellement dessus.

On peut ajouter aussi que parcourir une liste en ayant recours aux get(index) peut être très pénalisant.
A ne faire que si l'on est sûr s'agit d'une ArrayList.
Personnellement, j'aurais écrit la boucle comme ça :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

Iterator it = maListe.iterator(); MaClasse monObjet = null; boolean ok = true; while(it.hasNext() && ok) { monObjet = (MaClasse) maListe.next(); String attribut1 = monObjet.getAttribut1(); ... if (<un certaine condition de sortie>) ok = false; }

---

Citation:

---

Envoyé par bouye

Citation:

---

l'opérateur + entre deux String

---

Exact ca c'est quelque chose de tres important et ni la doc ni les livres n'insistent réellement dessus.

---

Très interessant comme point. Donc dans ce genre de cas, il faut utiliser un StringBuffer ?

Avant Java 5.0 => StringBuffer
Depuis Java 5.0 => StringBuilder (sauf si on a besoin d'une synchronisation a ce moment-là on peut utiliser StringBuffer).

Voir la FAQ.

Citation:

---

Envoyé par NGY

On peut ajouter aussi que parcourir une liste en ayant recours aux get(index) peut être très pénalisant.
A ne faire que si l'on est sûr s'agit d'une ArrayList.

---

En effet sur une grosse LinkedList cela peut être assez pénalisant... mais même sur une ArrayList cela n'est pas super "propre" comme traitement (en particulier si on supprime des éléments de la liste)... Il est preferable de toujours utiliser l'itérateur (et encore plus avec Java 5.0 et le for étendu).

Citation:

---

Envoyé par sleepy2002

Très interessant comme point. Donc dans ce genre de cas, il faut utiliser un StringBuffer ?

---

Oui car sinon le compilateur utilisera un StringBuffer pour chaque itération de la boucle... Cf la FAQ : Comment concatener des chaînes de caractères ?.

a++

Le seul truc ki me gène dans ce code c de déclarer et de recréer a chaque fois la variable.... c pas top niveau mémoire. Mais vu les capacité des mémoires maintenant. C sur ke nous aussi les profs d'algo nous ont cassé les pieds avec ça. mais je suis d'accord c aps très joli comme sode.

Citation : Effective Java Programming Language Guide, Joshua Bloch, The Java Series - Addision Wesley ISBN 0-201-31005-8

Note : j'ai mis en gras ce qui est en gras dans le bouquin.

Page 141

Citation:

---

Item 29: Minimize the scope of local variables

This item is similar in nature to Item 12, "Minimize the accessibility of classes and members." By minimizing the scope of local variables, you increase the readability and maintainability of your code and reduce the likelihood of error.
The C programming language mandates that local variables must be declared at the head of the block, and programmers continue to do this out of habit; it's a habit worth breaking. As a reminder, the Java programming language lets you declare variables anywhere a statement is legal.
The most powerful technique for minimizing the scope of a local variable is to declare it where it is first used.
( ... )

---

Le reste de l'item indique pourquoi les boucles for sont préférables aux boucles while.

Page162

Citation:

---

Item 37: Optimize judiciously

There are three aphorisms concerning otptimization that everyone should know. They are perhaps beginning to suffer from overexposure, but in a case you aren't yet familiar with them, here they are:

- More computing sins are commited in the name of efficiency (without necessarly achieving it) that for any other single reason - including blind stupidity.
- Wiliam A. Wulf (A case Agains the GOTO, Proceedings of the 25th ACM NAtional Conference 2 (1972))

- We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.
- Donald E. Knuth (Structured Programming with go to Statements, Computing Survey 6 (1974)).

- We follow two rules in the matter of optimization :
Rule 1. Don't do it.
Rule 2 (for experts only). Don't do it yet - that is, not until you have a perfectly clear and unoptimized solution.
- M. A. Jackson (Principles of Program Design, Academic Press (1975))

All of there aphorisms predate the Java programming language by two decades. They tell a deep truth about optimization: it's easy to do more harm than good, especially if you optimize prematurely. In the process, you may produce software that is neither fast nor correct an cannot easily be fixed.
Don't sacrifice sound architectural principles for performance. Strive to write good programs rather than fast ones.
( ... )

---

En gros
1) soyez vraiment sur que le programme marche bien avant d'optimiser.
2) n'optimisez pas quand ce n'est pas nécessaire*.
3) essayez d'optimizer l'architecture plutot que le code.

*Systeme temps réel/critiques/embarqués = oui mieux vaut faire des optimisations après vérification que le programme marche.
postes clients = êtes-vous vraiment sûrs que le jeu en vaut la chandelle ?

Bonjour,

pour moi déclarer des variables dans une boucle est, sauf justifications, définitivement une horreur que le compilateur ne peut pas optimiser.

Comme indiquer dans ce thread, il existe des cas ou il est nécessaire de le faire (ces variables sont utilisée par ailleurs). Je ne vois pas comment le compilateur pourrait savoir quand déporter et quand ne pas le faire.

Il ne faut pas oublier que souvent gain de mémoire = gain de performance (moins de passage du gc) même avec des serveurs à 1 Go de RAM.

Par contre il est inutile d'utiliser des stringBuffer si on a le code suivant

Code:

---

1 2	chaine = "debut de la phrase " +"fin de la phrase";

---

ça le compilateur sait le faire tout seul.

un site de best practice J2EE :

http://www.javapractices.com/index.cjp


Je suis d'accord toutes les applications ne mérite pas une campagne de profiling mais il est des modifications qui ne coute rien (déclarer les variables en dehors de la boucle n'est pas plus difficile que de le faire à l'intérieur).

return dans la boucle for.
Effectivement c'est pas beau mais si le client l'accepte (de plus en plus font des revues de code et impose des conventions de codage)

NGY : tu ne peux pas être derrière chaque developpeur et je te conseille l'utilisation d'outils comme checkstyle ou findbugs