Pourquoi ce livre
Pourquoi écrit-on un livre ? Chaque auteur aura sa réponse, la mienne est que je ressens le besoin de faire partager ce que j’apprends. Comme lorsque je fais des cours à l’université ou des formations internes à mes collègues, j’ai envie de faire comprendre aux autres.
Or, suite à de nombreux audits de code sur des problématiques de performance, je me suis rendu compte de quelque chose d’important, que dis-je… de fondamental : la performance d’une application n’est pas une affaire d’experts. Et j’ai eu envie de le faire savoir. D’où ce livre :
Pour ceux qui savaient, j’enfonce une porte ouverte. J’ai failli écrire “c’est une tautologie”, mais on m’aurait encore reproché d’étaler ma littérature. Or, étaler sa science en écrivant un bouquin devrait déjà suffire à me classer dans la catégorie des fortes-chevilles. Mais revenons à nos moutons : personnellement, il y a quelques années à peine, la notion de performance de code me paraissait relever de l’expertise. Pour écrire du code rapide, il fallait faire du tuning applicatif, voire réécrire certains blocs en C, etc.
En fait, je me suis rendu compte au fur et à mesure d’audits de performance que dans l’énorme majorité des cas, l’utilisation d’un logiciel de profilage du code me désignait relativement vite le code coupable, et que sa lenteur relevait presque toujours d’une programmation correcte fonctionnellement, mais simplement lente. Sur plusieurs dizaines d’améliorations de performances, je n’ai fait que modifier légèrement du code pour le rendre plus rapide. Jamais je n’ai dégainé les armes du tuning : pas de codage de portions en C, pas de mise en place de caches complexes, pas de scale-out…
Déçus ?
Peut-être le serez-vous… Quand on recherche les blogs sur la performance, on trouve énormément d’articles sur des cas de tuning extrêmes, techniquement très complexes et qui nécessitent une énergie phénoménale pour aller chercher quelques derniers pourcents. Vous trouverez également des tas d’articles sur les architectures spéciales mises en place par Google et consorts pour supporter des charges énormes avec des temps d’accès très bas.
Désolé de vous décevoir, mais le quotidien d’un développeur spécialisé dans la performance est de régler les quelques 20% d’erreurs traditionnelles qui représentent 80% des lenteurs. Parce qu’en plus, ces erreurs sont bien connues, et vous les avez certainement tous déjà vues : des appels de requêtes SQL en boucle, des concaténations de chaines multiples au lieu d’utiliser un StringBuilder, etc. Rien de très sexy, pas de découverte extraordinaire ou de méthodes hautement intellectuelles. Vous ne trouverez dans ce livre aucune surprise…
Ce que vous trouverez, par contre, ce sont des méthodes pour profiler rapidement une application .NET, identifier au plus vite dans les résultats les indices de telle ou telle erreur, puis la façon la plus efficace de traiter.
Contenu
En plus de ces méthodes d’identification rapide et de résolution des problèmes traditionnels de performance (et une checklist pour les plus pressés), vous trouverez dans ce livre un exemple d’analyse pour chaque cas. J’ai créé une application sur mesure qui regroupe tous les “smells” (inverses de “patterns”) possibles, et les chapitres vous accompagneront dans le profilage et la correction progressive de cette application. Pas à pas, vous passerez d’un pot-pourri de toutes les erreurs de code en termes de performance à une application affûtée… et trois fois plus rapide en moyenne, avec des pointes à 100 fois plus rapide pour certains traitements !
Les premiers chapitres vous exposeront des principes de base de la gestion de la performance en général, ainsi qu’une étude avancée des fonctionnalités de .NET liées à la rapidité d’exécution. En toute immodestie, je pense que le chapitre sur la gestion de la mémoire est ce que vous pourrez trouver de plus complet à ce jour en langue française.
Enfin, je n’ai bien sûr pas pu résister à étendre le sujet au tuning et à la réarchitecture. Ce n’est pas parce que le profilage simple résout 95% des problèmes qu’il ne fallait pas parler des 5% restants. Scale-up ou scale-out, techniques de persistance innovantes, etc. Si le profilage ne suffit pas, vous aurez les pistes pour passer à l’échelon supérieur.
Référence
Bon, après tout ça, si je ne vous ai pas donné envie de lire ce livre, je ne vois pas ce que je peux dire de plus…
Si vous vous dites par contre que vos applications pourraient supporter de voir leur temps d’exécution divisé par deux en apprenant quelques méthodes simples et en investissant une somme absolument ridicule, c’est par ici : Editions ENI – Ecrire du code .NET performant.
Préface par notre dieu en personne !
Et pour les plus geeks d’entre vous : la préface a été écrite par Eric Mittelette ! Notre gourou à tous, celui qui a accompagné nos premiers Tech Days, qui nous a expliqué comment créer une classe en .NET, Monsieur “Mieux que des mots, démo !”, m’a fait l’honneur de supporter mon humble contribution à une bonne pratique de .NET.
Eric, évangéliste .NET de la première heure, responsable de l’équipe relation avec les développeurs, et surtout une des rares personnes à parler sérieusement d’écologie dans l’informatique, était le signataire de rêve pour cette préface : l’optimisation logicielle est, à notre avis, une prochaine étape du Green IT.
J’ai toujours eu des regrets sur ma thèse en écologie : elle a reçu le prix Cherry de Cranfield University, mais je n’ai pas su diffuser le logiciel EOLE qui en était le produit et participer ainsi à une conception plus écologique des produits manufacturés. J’espère que ce livre va montrer à de nombreux développeurs que quelques méthodes simples permettront d’acheter moins de machines, de consommer moins de CPU, d’électricité, de mémoire, de climatisation, etc.
Voila, voila… c’était la séquence “auto-promotion”. Maintenant, je compte sur vous pour filer l’acheter, et en faire la publicité à tous vos collègues et amis !
La planète vous remercie… et moi aussi 
