Java Language Une approche basée sur des preuves pour l'optimisation des performances Java


Exemple

Donald Knuth est souvent cité comme disant ceci:

« Les programmeurs gaspillent des quantités énormes de temps à penser à, ou se soucier, la vitesse des parties non critiques de leurs programmes, et ces tentatives d'efficacité ont en fait un fort impact négatif lorsque sont considérés comme le débogage et la maintenance. Il faut oublier les petits gains d' efficacité, disent 97% du temps : l'optimisation prématurée est la racine de tous les maux. Pourtant, nous ne devrions pas laisser passer nos opportunités dans ces 3% critiques. "

la source

Compte tenu de ce conseil avisé, voici la procédure recommandée pour optimiser les programmes:

  1. Tout d'abord, concevez et codez votre programme ou votre bibliothèque en mettant l'accent sur la simplicité et l'exactitude. Pour commencer, ne consacrez pas beaucoup d'efforts à la performance.

  2. Mettez-le en état de marche et, idéalement, développez des tests unitaires pour les éléments clés du code.

  3. Développer un benchmark de performance au niveau applicatif. Le test de performance doit couvrir les aspects critiques de votre application en termes de performances, et effectuer une série de tâches typiques de l’utilisation de l’application en production.

  4. Mesurer la performance.

  5. Comparez les performances mesurées à vos critères pour déterminer la rapidité avec laquelle l'application doit être. (Évitez les critères irréalistes, irréalisables ou non quantifiables tels que "aussi vite que possible".)

  6. Si vous avez satisfait aux critères, STOP. Votre travail est terminé. (Tout effort supplémentaire est probablement une perte de temps.)

  7. Profil de l'application pendant qu'elle exécute votre test de performances.

  8. Examinez les résultats du profilage et sélectionnez les "zones sensibles de performance" les plus importantes (non optimisées). c'est-à-dire des sections du code où l'application semble passer le plus de temps.

  9. Analysez la section de code du hotspot pour essayer de comprendre pourquoi il s’agit d’un goulot d’étranglement et réfléchissez à un moyen de le rendre plus rapide.

  10. Implémentez cela comme un changement de code proposé, testez et déboguez.

  11. Réexécutez le test pour voir si le changement de code a amélioré les performances:

    • Si oui, retournez à l'étape 4.
    • Si non, abandonner le changement et retourner à l'étape 9. Si vous ne faites aucun progrès, choisissez un autre point sensible pour votre attention.

Finalement, vous arriverez à un point où l'application est soit assez rapide, soit vous avez considéré tous les points chauds significatifs. À ce stade, vous devez arrêter cette approche. Si une section de code consomme (disons) 1% du temps total, alors même une amélioration de 50% ne fera que rendre l'application 0,5% plus rapide.

Clairement, il existe un point au-delà duquel l’optimisation des points d’accès est une perte de temps. Si vous arrivez à ce stade, vous devez adopter une approche plus radicale. Par exemple:

  • Regardez la complexité algorithmique de vos algorithmes de base.
  • Si l'application consacre beaucoup de temps à la récupération de place, recherchez des moyens de réduire le taux de création d'objets.
  • Si des parties clés de l'application consomment beaucoup de ressources processeur et sont à thread unique, recherchez les opportunités de parallélisme.
  • Si l'application est déjà multithread, recherchez les goulots d'étranglement de concurrence.

Mais dans la mesure du possible, utilisez des outils et des mesures plutôt que l'instinct pour diriger votre effort d'optimisation.