Faut-il sacrifier la performance pour avoir un code plus lisible ?
Selon un développeur, la performance passe au second degré
Le 2015-05-07 09:08:43, par Amine Horseman, Expert éminent sénior
Un billet de blog sur Simplify C++! a attiré notre attention, selon son auteur : le C++ aujourd’hui est très performant, mais il ne faut jamais sacrifier la simplicité du code pour gagner en performance.
Le premier argument qu’il cite est que la performance et l’efficacité sont deux choses différentes. En effet, selon ses explications : la performance s’intéresse à la vitesse d’exécution d’une certaine tâche, alors que l’efficacité s’intéresse au temps qu’il faut pour la réaliser. « À première vue, cela peut sembler pareil » déclare-t-il, « mais ce n’est pas le cas. Imaginez que vous devez aller d'un point A à un point B. l’efficacité signifie que vous allez prendre le plus court chemin. La performance signifie que vous allez courir au lieu de marcher ».
Pour lui, il suffit parfois de rendre le code « plus efficace pour obtenir la vitesse souhaitée sans avoir à se soucier des détails de performances », le tout en gardant à l’esprit que la majeure partie du code « ne s’avère pas vital pour la performance globale du programme » et donc son optimisation est inutile.
Mais pourquoi alors la performance n’est pas si importante que cela pour l’auteur du blog ? Tout simplement parce que selon lui « nous ne savons pas vraiment comment écrire du code performant ». Pour appuyer son argument, il explique que le facteur essentiel pour la performance réside dans le nombre d’instructions que le processeur doit exécuter, et ceux-ci « ne sont pas écrit par nous, mais plutôt par le compilateur et son optimiseur », en d’autres termes : « si nous avons vraiment à nous soucier de la performance, nous ne pouvons pas compter sur notre imagination ou sur l'expérience, nous devons utiliser un outil » par exemple « utiliser un profileur ».
Le plus important selon lui c’est d’écrire un code lisible, maintenable et aussi simple que possible. Toutefois, « si vous avez réellement un problème de performance et l'avez localisé, il y a encore de nombreuses options qui sont plus prometteuses que de transformer votre code en un désordre performant, mais complètement illisible », il suffit par exemple de :
Source : Simplify C++ !
Et vous ?
Le premier argument qu’il cite est que la performance et l’efficacité sont deux choses différentes. En effet, selon ses explications : la performance s’intéresse à la vitesse d’exécution d’une certaine tâche, alors que l’efficacité s’intéresse au temps qu’il faut pour la réaliser. « À première vue, cela peut sembler pareil » déclare-t-il, « mais ce n’est pas le cas. Imaginez que vous devez aller d'un point A à un point B. l’efficacité signifie que vous allez prendre le plus court chemin. La performance signifie que vous allez courir au lieu de marcher ».
Pour lui, il suffit parfois de rendre le code « plus efficace pour obtenir la vitesse souhaitée sans avoir à se soucier des détails de performances », le tout en gardant à l’esprit que la majeure partie du code « ne s’avère pas vital pour la performance globale du programme » et donc son optimisation est inutile.
Mais pourquoi alors la performance n’est pas si importante que cela pour l’auteur du blog ? Tout simplement parce que selon lui « nous ne savons pas vraiment comment écrire du code performant ». Pour appuyer son argument, il explique que le facteur essentiel pour la performance réside dans le nombre d’instructions que le processeur doit exécuter, et ceux-ci « ne sont pas écrit par nous, mais plutôt par le compilateur et son optimiseur », en d’autres termes : « si nous avons vraiment à nous soucier de la performance, nous ne pouvons pas compter sur notre imagination ou sur l'expérience, nous devons utiliser un outil » par exemple « utiliser un profileur ».
Le plus important selon lui c’est d’écrire un code lisible, maintenable et aussi simple que possible. Toutefois, « si vous avez réellement un problème de performance et l'avez localisé, il y a encore de nombreuses options qui sont plus prometteuses que de transformer votre code en un désordre performant, mais complètement illisible », il suffit par exemple de :
- Utiliser les structures de données les plus performantes possible
- Connaître et utiliser des bibliothèques de code performantes
- Toujours utiliser un profileur
Source : Simplify C++ !
Et vous ?
-
CodeurPlusPlusEn attente de confirmation mailLe débat est de toute façon biaisé dès le départ, puisque la majorité des programmeurs travaille sur des applications dans lesquelles il n'y a pas besoin de haute performance.
C'est facile de prétendre que "on peut faire performant tout en restant lisible". Le problème c'est que cela peut être vrai ou faux selon les définitions qu'on donne à "performant" et à "lisible".le 08/05/2015 à 16:33 -
Luckyluke34Membre émériteCa dépend bien évidemment du contexte. Il n'y a pas de réponse universelle.Quel est le critère le plus important pour vous dans un code source ?
J'écoutais récemment une interview d'un développeur de jeux mais qui faisait auparavant des applications d'entreprise. Il a dû changer complètement d'état d'esprit. Dans les jeux qui sortent en boîte avec une version définitive, la performance prime sur la lisibilité. Dans une "line of business application" qui est en perpétuel changement, la lisibilité est au moins aussi primordiale, question de maintenabilité.
Mais j'ai tendance à croire qu'il est beaucoup plus facile de rendre performante une application déjà lisible que l'inverse.le 12/05/2015 à 13:32 -
dfiad77proMembre expérimentéLe soucis c'est que si on sacrifie la performance, l'utilisateur en a rien a faire du code, il va juste avoir envie de jetter son PC par la fenêtre
Faut trouver un équilibre. Et aussi travailler sur la scénaristique.
souvent les appli on des méthodes très unitaires pour des questions de maintenance, ce qui fait qu'on parcours plusieurs fois les mêmes éléments.
Coté requête SQL on retrouve souvent des données non mises en cache et ça joue si on a pas besoin de temps réel.
L'argument de base des entreprises sur une fonctionnalité lente de leurs logiciels internes : "oui mais sans cette fonctionnalité, vous mettriez 2 heures à faire tout à la main"
, sauf que quand le cercle de chargement tourne pendant 2 minutes l'utilisateur à envie de ce pendre et le service informatique à mauvaise réputation.le 07/05/2015 à 10:24 -
ManusDeiExpert confirméEn gros c'est une réécriture de "On passe 80% du temps dans 20% du code, donc pas besoin de perdre trop de temps à optimiser les 80% du code où on passe 20% du temps".le 07/05/2015 à 11:05
-
HelpmeMMMembre éprouvéComparé performance et efficacité...
mouais c'est de la masturbation intellectuelle
si ton code est efficace en terme de temps , c'est qu'ils est performant et si il est performant c'est qu'il est efficace. il joue sur les mot et sur des synonymes.
La vrai question est plutôt est ce que recherché la performance et l'éfficacité , implique nécessairement un code complexe ?
puis-qu’apparemment c'est à ça qu'il veut en arriver , ne chercher pas la performance , chercher plutôt la simplicité du code.
j'avoue que le titre est racoleur et ne reflète pas forcement la pensé de cette "étude".
Mais bon si ton code est simple et que ton programme n'avance pas c'est pas la peine de passé a l'étape livrable.le 07/05/2015 à 11:29 -
NoPr0nMembre régulierLe cas d'un développement de jeu est un cas bien particulier à ne pas comparer avec du développement logiciel.
1ms de chargement supplémentaire dans un appli (même très grosse) c'est quasiment négligeable, 1ms de chargement entre 2 frame dans un jeu et ton jeu peu devenir injouable(ce chiffre est tiré du chapeau, mais vous voyez l'idée).le 07/05/2015 à 13:25 -
el_slapperExpert éminent séniordans mes bras!!!
La seule réponse valable, est "ça dépend". Il m'est arrivé de sacrifier pas mal de bonnes pratiques(avec un algo à la puissance 4!!!) de performances sur un traitement qui ne tournait qu'une fois par mois. Parcequ'il fallait que ça marche, et éventuellement que ça soit lisible(ça ne l'était pas vraiment, mais un autre algo aurait été pire). Faire la même chose sur de l'embarquéle 07/05/2015 à 14:24 -
GlutinusInactifJe dirai bien : first make it work, then make it fast, then make it clean.
Même si des fois, les trois sont liés.
Un truc bien pensé au début va te faire comprendre, sans pour autant pinailler, quelque chose qui est bon et qui va aller plus vite, et qui sera clair.
Ceci dit, j'aimerai bien un jour dire au client ou aux utilisateurs :
"Je vais refactorer le code, ça va être très propre et je vais bien me relire, mais au lieu de mettre 30 secondes ça va mettre 2 minutes"le 07/05/2015 à 16:01 -
frantzgacMembre actifSacrifier est un terme un peu dramatique pour un enjeu simplement pragmatique.
La performance d'un code ne dégrade pas nécessairement sa lisibilité surtout si on commente un peu et/ou qu'on rédige une référence documentaire.
Dans certains cas la performance est cruciale. Je me souviens d'avoir réduit de 8h à 2h un traitement de crédit documentaire pour la société générale qui tournait tous les vendredi. Il s'agissait bien là de gagner du temps pour éviter de retarder des opérations de 48h sous prétexte que la fin du programme arrivait après le départ du personnel en WE. Plus récemment j'ai optimisé une application de prise de rendez vous pour les secrétariats d'écoles médicales. Je ne peux imposer à mon client de remplacer tous ses PC d'occase par des Core I7 il faut bien dans ce cas repérer les gâchis de CPU et les éliminer.
Il n'y a guère de règle absolue dans ce domaine, tout se calcule et s'évalue.le 17/05/2015 à 22:21 -
temoanatiniMembre avertiNon. Demandez au client...c'est (presque) toujours la même chose.« À première vue, cela peut sembler pareil » déclare-t-il, « mais ce n’est pas le cas. Imaginez que vous devez aller d'un point A à un point B. l’efficacité signifie que vous allez prendre le plus court chemin. La performance signifie que vous allez courir au lieu de marcher »le 07/05/2015 à 9:51