Faut-il sacrifier la performance pour avoir un code plus lisible ?

Faut-il sacrifier la performance pour avoir un code plus lisible ?
Selon un développeur, la performance passe au second degré

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 :

• 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 ?

:fleche: Êtes-vous d’accord avec l’avis de l’auteur du blog ?
:fleche: Peut-on avoir un code qui soit à la fois efficace, lisible, et performant ?

Non. Demandez au client... :?

Citation:

---

« À 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 »

---

c'est (presque) toujours la même chose.

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 :mrgreen:

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.

Je ne suis pas d'accord,
à l'heure de la mobilité, la performance est importante et je trouve un peu étrange d'avoir un discours qui privilégie le code lisible au code performant. D'ailleurs je ne vois aucun lien entre un code performant et un code lisible. Un code performant est écrit par un programmeur qui connaît bien le langage, les structures de données, le compilateur ainsi que l'architecture de la machine sur la quelle il travaille. Un code lisible est écrit par un développeur soucieux de la ré-utilisation de son code ainsi que de sa modularité, etc. Ce sont donc deux contextes de programmation différents et ils peuvent très bien être complémentaires.

Attention que dans l'article la distinction est faite entre performance et efficacité.

Avec vos réponses, je n'arrive pas à savoir si vous répondez en tenant compte de cette distinction ou si vous réagissez juste par rapport au titre de l'article sans l'avoir lu. :(

Cela dépend de la cible finale.
Si c'est un traitement de texte pour un ordinateur de bureau... La performance importe peu, sauf si on tombe dans l'extrême.
Si c'est un programme destiné à tourner sur une centrale nucléaire... Qui oserait répondre autre chose que performance et une bonne formation des développeurs sur cette partie du code ?

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".

tout dépend de l’utilité du soft.

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.

Citation:

---

Envoyé par Amine Horseman

« 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 ».

---

Alors qu'il faut prendre le chemin le plus rapide et non le plus court.

Donc enfaite le code de Windows millénium est super lisible alors que celui de Windows 7 non ?

L'utilisateur finale lui n'est pas développeur donc ses priorités sont différentes du développeur

Un code lisible et bien structuré a rarement des perf désastreuses et il est en général très facilement maintenable.
Autrement dit, en cas de fuite mémoire identifiée, elle est rapide et simple à corriger

Par expérience, les équipes fonctionnelles veulent de la réactivité (la planif et l'anticipation n'est pas tjrs leur point fort, et c'est un euphémisme)
Du coup, l'un des axes les plus forts de la satisfaction client provient de la rapidité des dev pour les correctifs et petites évolutions
Un code lisible et bien structuré permet cette réactivité

De plus, avec le cloud et la virtualisation, migrer de serveur est devenu particulièrement simple et rapide
Si l'appli rame, il est assez simple de la migrer sur un serveur plus puissant pour combler
Les charges salariales sont tellement élevées qu'il est souvent moins coûteux d'investir dans des bécanes plus puissantes que dans des jours/hommes à faire de l'optimisation de code

Citation:

---

Envoyé par Saverok

Un code lisible et bien structuré a rarement des perf désastreuses et il est en général très facilement maintenable.

---

Ca reste encore à prouver. Après, il est généralement possible d'arrive à un code performant bien structuré et facile à lire/maintenir. Il y avait une vidéo il n'y pas si longtemps dans la rubrique jeux d'un développeur d'ubisoft qui disait qu'ils s'interdisaient (pour les parties C++) d'utiliser les méthodes virtuelles, la STL et les allocateurs "classiques" (et sans doute quelques autres choses bien utiles). A partir de là j'ai du mal à voir comment on peut facilement faire du code lisible en se privant d'autant d'abstraction.

La "performance globale" d'une application ne peut pas être atteinte en optimisant le code au quart de poil près sur l'ensemble du code (en rendant illisible par la même occasion), mais en adoptant l'architecture adéquate pour cette application. Tuner un code n'a de sens que pour les rares fonctions qui sont appelées des millions de fois et qui sont très liées à la performance globale de l'application, mais ça n'est pas le cas de toutes les applications.
Très souvent on va gagner peut-être quelques % sur le temps d'exécution d'une fonction en la tunant (ok des fois un peu plus), alors qu'en passant d'une architecture pourrie à une architecture plus adaptée on peut faire facilement *2 ou *4 sur les perfs globales. Mais changer d'archi est évidemment beaucoup plus lourd en terme de boulot.

Citation:

---

Envoyé par codec_abc

Ca reste encore à prouver. Après, il est généralement possible d'arrive à un code performant bien structuré et facile à lire/maintenir. Il y avait une vidéo il n'y pas si longtemps dans la rubrique jeux d'un développeur d'ubisoft qui disait qu'ils s'interdisaient (pour les parties C++) d'utiliser les méthodes virtuelles, la STL et les allocateurs "classiques" (et sans doute quelques autres choses bien utiles). A partir de là j'ai du mal à voir comment on peut facilement faire du code lisible en se privant d'autant d'abstraction.

---

Le 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).

Citation:

---

Envoyé par NoPr0n

Le 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).

---

en jeu vidéo tu peut commencer à voir la différence entre frame sur l'interval 10-30 ms cela varie en fonction des individus et de l'age

Citation:

---

Envoyé par cuicui78

tout dépend de l’utilité du soft.

---

dans 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é :aie:

Citation:

---

Envoyé par NoPr0n

Le cas d'un développement de jeu est un cas bien particulier à ne pas comparer avec du développement logiciel.

---

Pas tant que ca. Les jeux vidéo font partie des applis temps réels. Et mine de rien le nombre d'applications temps réels (souples ou durs) est assez conséquent pour qu'on ne pusse pas dire que ce type de développement soit marginal.

Je 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" :aie:

Citation:

---

Envoyé par Glutinus

(.../...)
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" :aie:

---

ça a été mon cas, dans l'exemple ci-dessus. Mais sur un batch total de 6 heures, une secondes ou une minute, tout le monde s'en fout. Par contre, un code lisible et maintenable et documenté, ça... mais le monde du batch est un peu différent, les "utilisateurs" ne sont pas choqués par certaines choses.

Citation:

---

Envoyé par Glutinus

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" :aie:

---

Sauf que quand tu auras refactoré pour être vraiment propre et lisible, ton code tourneras en 20 secondes au lieu de 30, et pas 2 minutes.

L'argument c'est du code "cochonné" pour la performance je connais, mais je n'ai jamais vu un code qui était plus lent après avoir été rendu propre et lisible.