Un développeur doit-il viser d'abord la lisibilité ou les performances ?

Question

Il arrive souvent qu'un développeur soit confronté à un choix entre deux façons de résoudre un problème : l'une est idiomatique et lisible, l'autre est moins intuitive, mais peut être plus performante. Par exemple, dans les langages basés sur le langage C, il existe deux façons de multiplier un nombre par 2 :

int SimpleMultiplyBy2(int x)
{
    return x * 2; 
}

et

int FastMultiplyBy2(int x)
{
    return x << 1;
}

La première version est plus simple à comprendre pour les lecteurs techniques et non techniques, mais la seconde peut être plus performante, car le décalage de bits est une opération plus simple que la multiplication. (Pour l'instant, partons du principe que l'optimiseur du compilateur ne détectera pas cette opération et ne l'optimisera pas, bien que cela soit également envisageable).

En tant que développeur, quelle serait la meilleure solution pour une première tentative ?

Answer 1

Tu en as oublié un.

Codez d'abord pour l'exactitude, puis pour la clarté (les deux sont souvent liés, bien sûr !). Enfin, et seulement si vous avez la preuve empirique que vous en avez réellement besoin, vous pouvez envisager l'optimisation. L'optimisation prématurée est vraiment un mal. L'optimisation vous coûte presque toujours du temps, de la clarté, de la maintenabilité. Vous feriez mieux d'être sûr que vous achetez quelque chose de valable avec ça.

Notez que les bons algorithmes ont presque toujours raison des réglages localisés. Il n'y a aucune raison pour que vous ne puissiez pas avoir un code correct, clair et rapide. Vous aurez une chance déraisonnable d'y parvenir en commençant par vous concentrer sur la "rapidité".

Answer 2

OMI la version la plus lisible en premier, jusqu'à ce que les performances soient mesurées et qu'une version plus rapide soit nécessaire.

Answer 3

Prenez-le de Don Knuth

L'optimisation prématurée est la racine de tous les maux (ou du moins de la plupart) en programmation.

Answer 4

Lisibilité à 100%.

Si votre compilateur ne peut pas faire l'optimisation "x*2" => "x <<1" pour vous -- trouvez un nouveau compilateur !

N'oubliez pas non plus que 99,9 % du temps de votre programme est consacré à attendre les entrées de l'utilisateur, les requêtes de la base de données et les réponses du réseau. À moins que vous ne fassiez le multiple 20 bajillion de fois, cela ne sera pas perceptible.

Answer 5

Dans votre exemple, 99,9999 % des compilateurs génèrent le même code dans les deux cas. Ce qui illustre ma règle générale - écrire d'abord pour la lisibilité et la maintenabilité, et optimiser seulement quand c'est nécessaire.