Présentation du problème
Les « meilleures pratiques » de programmation enseignées aujourd'hui peuvent être des catastrophes en termes de performances. L'article examine les coûts de performance réels de la mise en œuvre de directives de « code propre ».
Les règles du code propre
Certaines des règles les plus souvent répétées pour un code propre incluent : préférer le polymorphisme aux instructions « if/else » et « switch », les fonctions ne doivent pas connaître les détails internes des objets avec lesquels elles travaillent, les fonctions doivent être petites et ne faire qu'une chose, et le principe « DRY » (Ne vous répétez pas). Ces règles sont spécifiques et affectent la structure du code.
class shape_base { public: virtual f32 Area() = 0; };Un exemple de mise en œuvre de ces règles est une hiérarchie de classes pour des formes géométriques, avec une classe de base et des classes dérivées pour des formes spécifiques comme le cercle, le triangle, le rectangle et le carré.
Performances du code propre
Pour évaluer les performances de ce code, nous pouvons utiliser une fonction qui calcule la surface totale d'une série de formes. La mise en œuvre « propre » utilise le polymorphisme et des fonctions virtuelles pour calculer la surface de chaque forme.
f32 TotalAreaVTBL(u32 ShapeCount, shape_base **Shapes) { f32 Accum = 0.0f; for(u32 ShapeIndex = 0; ShapeIndex ShapeCount; ++ShapeIndex) { Accum += Shapes[ShapeIndex]->Area(); } return Accum; }Les résultats montrent qu'il faut environ 35 cycles pour calculer la surface d'une forme en utilisant cette approche. Cela suggère que suivre les règles de code propre peut entraîner des performances médiocres.
Comparaison avec d'autres approches
Si l'on viole la première règle et utilise à la place une instruction « switch » pour calculer la surface, on obtient des résultats similaires. Cela montre que les règles de code propre ne sont pas toujours les meilleures en termes de performances.
