Pour cette session, mes retours prendront un ton certainement un peu différent des précédents compte-rendu, dans le sens où j’ai eu la chance d’être un des présentateurs, avec Olivier Philippot de Kaliterre et Eric Mittelette, évangéliste en chef de Microsoft (et par voie de conséquence, notre dieu à tous) 
.
C’était un grand plaisir de présenter aux Tech Days, devant une salle bien remplie, et avec des gens curieux qui nous ont posé plein de questions à la fin. Important aussi de voir que ces sujets du GreenIT et de l’éco-conception logicielle attirent désormais plus qu’un public confidentiel.
Le message fort de cette session était qu’il est extrêmement facile de réaliser des gains substantiels d’énergie.
Olivier a commencé à le montrer en utilisant un système logiciel de mesure de la consommation sur une page web. L’optimisation des images et des CSS, voire la suppression de certaines ressources non utilisées a permis d’atteindre 45% de baisse de consommation. Au final, sur un site fortement sollicité comme celui d’un journal, ce sont 30 tonnes équivalent CO² qui sont économisés, soit 154 000 kms en voiture…
 |
 |
J’ai ensuite pris le relai pour montrer une mesure physique (avec une simple prise Plugwise et un dongle USB pour recueillir la donnée) sur l’application qui me sert d’exemple dans mon livre sur la performance. Entre la version mal codée et celle correcte du point de vue de l’utilisation des ressources, on passe sur un scénario automatisé simplissime de 11 secondes avec un pic à 20 W à 6 secondes avec un pic à 6 W.
Au final, 83% de gain de consommation, soit 3000 € gagnés sur ce seul scénario replacé dans le cycle de vie global de l’application. Le tout sans formation particulière car il s’agit de respecter simplement 5 règles de base que n’importe qui se prétendant développeur connait :
- Utiliser StringBuilder pour des concaténations nombreuses de chaînes
- Ne pas faire des appels de services web ou de requêtes SQL en boucle
- Sortir le plus rapidement possible des boucles
- Ne réaliser que les opérations immédiatement utiles (lazy loading)
- N’utiliser des exceptions que dans les cas effectivement exceptionels
Un autre message important, que nous n’avions pas préparé, mais qui est apparu dans la discussion, est l’effet de seuil important entre l’augmentation de performance par optimisation du code, et l’augmentation de performance par ajout de ressources. La première est “gratuite” et doit être favorisée, car elle aide sur toute la chaîne (nombre de machines, consommation électrique, besoin de climatisation, de locaux, etc.). La seconde est à n’utiliser que lorsque la première a été utilisée.
Comment savoir où on se place sur ce seuil et quand on l’a traversé trop vite ? Très simple : employez de VRAIS développeurs, des gens qui seront fiers de leur code, qui auront réalisé un travail de qualité, et sur lequel vous pouvez compter pour tirer la quintessence des ressources de la machine, avant de penser à rajouter un autre serveur.
Pour vérifier, il suffit de mesurer :
 |
 |
Mais comment reconnait-on le bon chasseur développeur du mauvais ? Difficile à dire, mais quelques exemples parmi tant d’autres :
- le bon développeur sait qu’il vaut mieux faire deux boucles sur la même liste pour réaliser deux traitements plutôt que de réaliser les deux traitements à chaque itération d’une seule boucle, car cette seconde solution réduit les chances d’optimisation du traitement par le cache du CPU.
- le bon développeur ne met pas un mécanisme de cache sur un traitement tant qu’il n’a pas la preuve par un profileur que le gain compense effectivement le coût en termes d’utilisation de la mémoire et de complexité de mise à jour.
- le bon développeur réfléchit LONGTEMPS à son code avant de taper la moindre ligne. Vous traverseriez un pont réalisé par un ouvrier qui n’a pas fait de calcul de résistance des matériaux avant de poser les poutrelles par dessus la rivière ?
Un autre moyen de trouver un bon développeur : regardez s’il est fier en cherchant le signe ci-dessous (il peut y avoir besoin, le cas échéant, de lui demander de retirer sa polaire élimée)
