Petite question sur les performances

Kupee wrote:

Salut, j'ai installé dans mon IDE un plugin d'inspection de code, qui me
rapporte entre autre toute champ de la classe dans une méthode utilisé
plus de 3 fois, et qui conseille pour des raisons de performances de
faire une copie locale de la référence, et si on la modifie de la
réallouer a la fin.
Bon je me doute que 3 fois dans une méthode utilisée rarement ca va rien
changer, mais si les accès sont vraiment très fréquents, est ce que
l'on constate vraiment une amélioration des performances (et de quel
ordre) ou c'est du pipi de chat ?

bien entendu c'est deja de la logique non?

en plus un appel de methode veut dir :
* si methode d'instance alors resolution de la table des methodes
virtuelles (RTTI comme en C++) a moins que la methode soit declaree "final"

* si methode synchronisee, surcout du lock associee a l'appel

* + tous les traitements (peut etre complexes) te permettant d'obtenir
ta reference

donc cela peut amener a des rapports de 1/1000 (Factory complexe,
synchronisation)
pire s'il y a utilisation de couches reseaux, resolution d'adresses DNS
etc...

convaincu ?
Jerome

jerome moliere wrote:

bien entendu c'est deja de la logique non?
en plus un appel de methode veut dir :
* si methode d'instance alors resolution de la table des methodes
virtuelles (RTTI comme en C++) a moins que la methode soit declaree "final"

* si methode synchronisee, surcout du lock associee a l'appel

* + tous les traitements (peut etre complexes) te permettant d'obtenir
ta reference

donc cela peut amener a des rapports de 1/1000 (Factory complexe,
synchronisation)
pire s'il y a utilisation de couches reseaux, resolution d'adresses DNS
etc...

convaincu ?

Je mettais déjà toutes mes classes qui n'avaient pas de filles en final,
je ferai un effort sur les fields lorsque j'y accède souvent dans des
méthodes critiques

jerome moliere wrote:

* si methode d'instance alors resolution de la table des methodes
virtuelles (RTTI comme en C++) a moins que la methode soit declaree "fi nal"

On sait combien représente le gain de performance sur le temps
d'invocation des méthodes dans le cas où elles ne sont pas virtuelles ?

Emmanuel

Emmanuel Bourg wrote:

jerome moliere wrote:

* si methode d'instance alors resolution de la table des methodes
virtuelles (RTTI comme en C++) a moins que la methode soit declaree
"final"

On sait combien représente le gain de performance sur le temps
d'invocation des méthodes dans le cas où elles ne sont pas virtuelles ?
le probleme est bien là justement , ce temps n'a rien de déterministe

puisqu'il dépend du contexte d'héritage...
c'est une des raisons qui fait que les gens faisant de l'embarqué
passent par du static...(moche hein :) )

Jerome

Je me suis amusé à faire un petit test dans lequel j'appelle en boucl e
une méthode vide 1 milliard de fois. Sur un P4 2.6Ghz avec la HotSpot
1.4.2 sous Windows XP ca me prend environ 5200ms, la différence quand l a
méthode est déclarée final est à peine perceptible, de l'ordre de 1%
maximum.

J'ai poussé le jeu un peu plus loin avec une hiérarchie de classes à 10
niveaux utilisée dans différents scénario :

Une méthode virtuelle surchargée dans chaque sous classe:
8400ms

Une méthode virtuelle non surchargée:
5140ms

Une méthode finale dans la classe de base (A):
5200ms

Une méthode surchargée et finale dans la dernière classe (H):
8340ms

Donc à priori surcharger une méthode coûte cher, mais ne pas la dé clarer
final si elle n'est pas surchargée ne change pas grand chose. Merci
HotSpot ? :) Les temps sont tellement infimes que ça ne vaut pas
vraiment le coup de s'en soucier à mon avis.

Emmanuel



public class InvocationTest {

public static void main(String[] argv) {

A a = new I();
long time1 = System.currentTimeMillis();
for (long i = 0; i < 1000000000; i++) {
a.a();
}
long time2 = System.currentTimeMillis();
System.out.println(time2 - time1);
}
}

class A { public void a() {} }
class B extends A { public void a() {} }
class C extends B { public void a() {} }
class D extends C { public void a() {} }
class E extends D { public void a() {} }
class F extends E { public void a() {} }
class G extends F { public void a() {} }
class H extends G { public void a() {} }
class I extends H { public void a() {} }