Discussion :

[rtg57]

Bonjour,

existe-t-il en JAVA une syntaxe qui remplacerait ce genre de code:

Code :

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

1
2
3
4
5
6
7
8
Btn_EnregistreF = new JButton(new CActionEnregistreF());
Btn_EnregistreF.setIcon(new ImageIcon("Images/Enregistre fichier.png"));
Btn_EnregistreF.setPressedIcon(new ImageIcon("Images/Enregistre fichier press.png"));
Btn_EnregistreF.setToolTipText("Enregistre les données dans un fichier");
Btn_EnregistreF.setPreferredSize(new Dimension(L_MINI_B, H_MINI_B));
Btn_EnregistreF.setCursor(Cursor.getPredefinedCursor(Cursor.HAND_CURSOR));

BarreOutils.add(Btn_EnregistreF);

par un truc du genre:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
Btn_EnregistreF = new JButton(new CActionEnregistreF());
with Btn_EnregistreF
{
  .setIcon(new ImageIcon("Images/Enregistre fichier.png"));
  .setPressedIcon(new ImageIcon("Images/Enregistre fichier press.png"));
  .setToolTipText("Enregistre les données dans un fichier");
  .setPreferredSize(new Dimension(L_MINI_B, H_MINI_B));
  .setCursor(Cursor.getPredefinedCursor(Cursor.HAND_CURSOR));
}

BarreOutils.add(Btn_EnregistreF);

La référence au composant étant utilisée plusieurs fois, il ne serait pas nécessaire de la calculer à chaque fois...

[laurentze]

Si tu as une classe MyJButton qui hérite de JButton dont tu modifies le constructeur, ça devrait le faire non?

[Desintegr]

Pour éviter de faire un lookup de membre à chaque fois que tu utilises Btn_EnregistreF, le plus simple est de faire un alias local alloué la pile de cette variable.

Code :

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

1
2
3
4
5
6
7
8
9
Btn_EnregistreF = new JButton(new CActionEnregistreF());
 
JButton Btn_EnregistreF_local = Btn_EnregistreF;
 
Btn_EnregistreF_local.setIcon(new ImageIcon("Images/Enregistre fichier.png"));
Btn_EnregistreF_local.setPressedIcon(new ImageIcon("Images/Enregistre fichier press.png"));
Btn_EnregistreF_local.setToolTipText("Enregistre les données dans un fichier");
Btn_EnregistreF_local.setPreferredSize(new Dimension(L_MINI_B, H_MINI_B));
Btn_EnregistreF_local.setCursor(Cursor.getPredefinedCursor(Cursor.HAND_CURSOR));

Il y a toujours autant de lookup, mais celle fois ci, la variable est cherchée sur la pile, ce qui est plus performant.

Ces pratiques sont notamment utilisées pour de l'embarqué.

[thelvin]

La référence au composant étant utilisée plusieurs fois, il ne serait pas nécessaire de la calculer à chaque fois...

Ces pratiques sont notamment utilisées pour de l'embarqué.

Hmm. Je ne sais pas pour l'embarqué, mais normalement je m'attends à ce qu'à moins que le membre soit déclaré volatile, le compilateur se charge tout seul de le garder sur la pile.
Après tout, c'est son boulot, pas celui du programmeur.

[thelvin]

Hmm. Je ne sais pas pour l'embarqué, mais normalement je m'attends à ce qu'à moins que le membre soit déclaré volatile, le compilateur se charge tout seul de le garder sur la pile.
Après tout, c'est son boulot, pas celui du programmeur.

Juste pour signaler que je me rends compte pourquoi c'est faux -_-° : ces appels de méthode pourraient possiblement modifier la variable membre. En effet, je n'y avais pas pensé.

[professeur shadoko]

Ces pratiques sont notamment utilisées pour de l'embarqué.

Ce qui est intéressant c'est la mise en garde au début ... et effectivement j'ai testé plusieurs de ces optimisations sur du non-embarqué et avec une JVM "normale" c'est d'un intérêt nul ou epsilonesque. 3 ou 4% de gain avec une copie locale et rien du tout si on passe par une interface plutot qu'une classe concrète par exemple (même avec une classe final!).

Du coup ça me rappelle les conseils d'optimisations donnés à propos des premières machines virtuelles Java. On avait beau dire "ne faites pas ça" les optims astucieuses étaient irresistibles (effectivement sur le moment il y avait des différences mais plus tard ça n'a plus été le cas ... dans certains cas c'était carrément contre-productif)..... et pourtant des optims à faire il y en a!

[rtg57]

Merci à tous pour l'intérêt que vous portez à ce post.

Personnellement, je pense que ce n'est pas parce que nous avons des ordinateurs que la NASA nous aurait envié il y a 10 ans, qu'il ne faut pas se soucier de l'efficacité d'un code, ou de son optimisation.

On constate aujourd'hui qu'avec des ordinateurs 1000 fois plus rapide qu'au début du siècle (il y a 10 ans ), il leur faut toujours autant de temps pour démarrer. (Certes Windows 7 et plus beau que Windows 3, et ça demande de la ressource).

Donc si je dois un peu me casser la tête pour faire dans l'efficace, je le ferai... d'où ce post (de débutant en JAVA).

Merci & @ bientôt.

[adiGuba]

Salut,

Donc si je dois un peu me casser la tête pour faire dans l'efficace, je le ferai... d'où ce post (de débutant en JAVA).

Ce n'est pas en économisant un caractère par ci par là que tu optimisera ton programme. En général ce genre de syntaxe ne correspond ni plus ni moins qu'à du sucre syntaxique, et génèrera donc exactement le même code...


Les optimisations ne se font pas sur des détails syntaxiques, mais sur les algorithmes seulement une fois que l'origine des mauvaises performances a bien été ciblé.


Toutes idées d'optimisations précoces n'apportent générale rien de bien bon...


a++

[professeur shadoko]

Donc si je dois un peu me casser la tête pour faire dans l'efficace, je le ferai... d'où ce post (de débutant en JAVA).

extrait du document cité en référence:

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.

edit: grilled