Ecrire des programmes performants en Java - considérations générales

Citation:

---

Envoyé par dingoth

Je vais en rester là, et prendre ma référence en matière de performances.

---

j'arrive un peu tard mais... ce livre ne commence t il pas à marquer son age ? Quand je vois 2000 je me dis que Java a bien évolué depuis, et du coup j'hésite à le mettre sur ma liste de lecture...

Voir ma réponse plus haut.

Citation:

---

Envoyé par dingoth

Voir ma réponse plus haut.

---

en effet, autant pour moi.. qui pensait avoir suivi toute la discussion.

merci bcp encore

++

Petie question rapide : on lit souvent qu'il faut adapter le conteneur au contenu, mais pourquoi oublie-t-on le type short? Même pour une petite boucle allant de 1 à 10 on utilise un compteur de type int. Y' a-t-il une raison particulière à cela?

Sinon Je n'ai pas le niveau pour critiquer mais j'ai bien aimé l'article, merci à son auteur.

Citation:

---

Envoyé par Bassas

Petie question rapide : on lit souvent qu'il faut adapter le conteneur au contenu, mais pourquoi oublie-t-on le type short? Même pour une petite boucle allant de 1 à 10 on utilise un compteur de type int. Y' a-t-il une raison particulière à cela?

---

Oui, il y a une raison. En Java, toutes les opérations entières se font avec des int, donc si tu utilises un short comme index de boucle, les calculs se feront quand même en int et tu il y aura un typecasting implicite vers short, ce qui va dégrader les performances. C'est vraiment faible, mais vérifiable. Par exemple si on fait 1000 fois une boucle de 0 à 32760 , le temps avec short est 1.5 fois plus grand qu'avec un int.

L'avantage du short par rapport au int serait au niveau de la mémoire utilisée, mais pour une variable locale à une boucle, ce n'est vraiment pas utile de gagner 2 octets.

Parfait, merci.

Sans vouloir répéter ce qui a été dit, je suis pas non plus très convaincu. Et j'ai aussi des doutes sur pas mal de points.
Je suis toutefois surpris de ne rien lire concernant l'autoboxing des primitifs. Sachant qu'utiliser des implémentations de collections de primitifs peuvent provoquer des améliorations très conséquentes.

L'article cite bien les type java 5, ce qui était un problème sur le 1er jet.

Mais il reste une erreur:

Citation:

---

V-J-2. Utiliser Serializable plutôt que Externalisable pour l'écriture des objets.
Pour en savoir plus :http://java.sun.com/developer/TechTi...0425.html#tip1

---

C'est juste le contraire que dit l'article cite: il faut utiliser Externalizable plutôt que Serializable.

Oui, l'autoboxing introduit par la V5 pose parfois des problème de perfs (et comme l'article semble partir d'un trame antérieure?...)

Et l'exemple d'économie d'objet (l'exception) me semble toujours problématique, on précise bien l'inconvénient dans l'article, mais il vaudrait mieux proposer un pattern poids-mouche:
http://rpouiller.developpez.com/tuto...ge=page_3#LV-F

Salut,



Il y a plusieurs points qui me chagrine un peu (certains ont peut-être déjà été cité je n'ai pas lu tous les commentaires) :

• IV-D-1-a. Les exceptions
  L'économie sur la création d'une exception est une fausse bonne idée.
  Bien sûr la création d'une exception a un certain coût en terme de temps d'exécution, mais c'est principalement pour la création du stacktrace si utile. Sans les exceptions sont complètement inutile...
  
  Imaginez un peu si toutes les NPEs renvoyait la même chose :
  
  Code:

  ---

  1 2	Exception in thread "main" java.lang.NullPointerException: null at Main.<clinit>()

  ---

  J'imagine même pas la galère pour débugger cela...
  
  
• IV-D-1-d. Les StringBuffer et les StringBuilder
  Le fait de passer d'une variable temporaire à un attribut est également problématique, car la méthode n'est plus thread-safe. De plus cela implique également une surcharge mémoire à cause de ce Stringbuffer qu'on conserve en mémoire...
  
  Dans ce cas précis (variable locale donc forcément mono-thread), il serait préférable d'utiliser un StringBuilder, éventuelle en spécifiant sa taille :
  
  Code:

  ---

  1 2 3 4 5 6 7 8

  public String toString(){ StringBuilder bf = new StringBuilder( /* taille approximative si possible */ ); //traitement de remplissage du buffer //?. //renvoi du resultat return bf.toString(); }

  ---

  
  
  
• V-H. Faire les déclarations en dehors des boucles
  C'est totalement inutile car la JVM gère cela proprement.
  Par contre cela augmente la portée de la variable :?
  
  
• V-I. Accélérer le processus de libération de la mémoire
  L'appel au GC est vraiment casse-gueule, et peut poser plus de problème qu'il n'en résoud :?
  Surtout que dans la plupart des cas cela génère un full-GC très couteux en temps même si ce n'est pas forcément neccessaire...
  
  
• Enfin plus globalement en Java la création d'objet n'est pas si couteuse que cela en Java, grace au GC et à la gestion de la mémoire ! Contrairement au C++ l'utilisation du mot-clef new n'implique pas forcément d'allocation mémoire puisque cette dernière est déjà alloué la majeur partie du temps...
  Le fait de vouloir réutiliser à outrance les objets peut au contraire poser des problèmes, car le GC ne pourra pas les supprimer.
  
  Pire en augmentant la portée des variables on augmente leurs durées de vie, donc la consommation mémoire, donc la charge du GC...
  

a++

C'est une bonne synthèse de ce qui a été dit en effet. Particulièrement concernant la StackTrace.
Et de toutes manières, si une exception est si probable qu'on peut se la ramasser dans 30% des cas en utilisation normale, c'est qu'il y a peut être un problème de conception.

Citation:

---

Envoyé par Baptiste Wicht

Oui, il y a une raison. En Java, toutes les opérations entières se font avec des int, donc si tu utilises un short comme index de boucle, les calculs se feront quand même en int et tu il y aura un typecasting implicite vers short, ce qui va dégrader les performances. C'est vraiment faible, mais vérifiable. Par exemple si on fait 1000 fois une boucle de 0 à 32760 , le temps avec short est 1.5 fois plus grand qu'avec un int.

L'avantage du short par rapport au int serait au niveau de la mémoire utilisée, mais pour une variable locale à une boucle, ce n'est vraiment pas utile de gagner 2 octets.

---

A ma connaissance sur un processeur 32bits utiliser du 16bits en espérant économiser de la mémoire est soit illusoire soit une perte de perf si économie réelle il y a (question d'alignement de mots mémoire). Et franchement économiser 16bits pour des indices de boucle quand on fait du java ... On est en 2010.

C'est juste mais ce n'est pas illusoire en terme de footprint si tu stockes des matrices denses. Par contre pour 2 ou 3 variables locales, ça a clairement pas de sens.

Un seul truc qui est bon à savoir, et pas abordé comme dans mon point précédent, c'est que le footprint d'un primitif boxé peut être conséquent.

A titre d'exemple :
boolean = 1 octet
Boolean = 8 (entête objet) + 1 (boolean) + 7 (alignement sur 8) = 16 octets

Ca peut changer suivant les jvm en revanche, mais il est bon à savoir que ce n'est pas forcément trivial.