Discussion :

[Saverok]

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.

Je suis totalement d'accord avec cette remarque
Depuis quand un code lisible et bien documenté est-il moins performant ??
Beaucoup de dev semblent oublier qu'avant l'exécution du code, il y a une phase de compilation
Autrement dit, ce n'est pas parce que ton code Java fait 50 lignes et l'autre 100 (mais décomposé et avec des commentaires, variables et méthodes bien nommées, etc) qu'il va s'exécuter plus vite à la fin ou consommer moins de mémoire

[Aiekick]

la perf ca consiste aussi a éviter d'utiliser des gros framework qui vous impose 20 fonctions quand seulement 2 vous sont utiles.

j'essai au max de me passer le plus possible des gros framework a moins de savoir exactement commet ils focntionnent

[MABROUKI]

bonjour

L'auteur du blog verse dans la laplissade et utilise des termes generaux et controverses....qu'on peut transposer dans n'importe quel métier ,de telle facon qu'on ne peut rien en tirer en tant qu'informaticien ...
Le seul sens qu'on peut attribuer à sa lapalissade ,si elle a un sens ,est le suivant:
- efficacite rime avec employer l'outil adequat à la tache...(utiliser un marteau pour tuer une mouche)
- performance rime avec habilite à manipuler l'outil...ce qui au minimum exige une tres bonne connaissance de l'outil..

[CodeurPlusPlus]

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

[B.AF]

J'ai jamais vraiment compris en quoi un code illisible et compliqué est performant. De même que j'ai rarement compris comment un code peut être lisible et nul (au pire ca me fait penser aux gens qui se mettent des conventions de nommages dans des langages de scripting pour avoir l'impression de faire du code).
De la même façon avec l'enseignement actuel et la sur-utilisation des frameworks, l'enfer est pave de bonnes intentions.
Un professionnel ne livre jamais un logiciel non performant et non maintenable, c'est juste du suicide économique, après dans les grandes boites bourrées de presta, je crois que tant que le budget est consomme, tout le monde s'en fout et on verse dans le débat scolaire. Et comme les vieux ont l'impression d'avoir tout vu et les jeunes de tout savoir, on se retrouve avec des mecs qui connaissent la réalité incapable de se transposer dans des technologies actuelles et des jeunes la tête pleine de pratiques que personne n'utilise vraiment mais qui savent les transposer dans des technologies que les boite adopterons quand ils seront eux même vieux, et la boucle sera bouclée.
Un dev performant, c'est celui qui fait que votre client ne vous coute pas de l'argent en maintenance tous les mois et qui permet de faire de la vraie marge sur le changement. Le reste, c'est de la littérature.

[DonQuiche]

En général, pour la grande majorité des programmes, écrire du code performant n'a aucun intérêt car le CPU est de toute façon cent fois plus puissant que nécessaire pour exécuter la version propre. Dans l'idéal on prend simplement le langage le plus productif qui soit et on écrit le code le plus propre le plus rapidement possible sans jamais se soucier de la performance car ça n'a aucun intérêt.

Et on obtient en bout de course un programme aussi véloce que peut le distinguer un être humain. J'ai plein de programmes ayant des traitements lourds avec boucles en O(n^2) et chargeant le GC avec 10k nouveaux objets d'un coup, le tout en moins de 10ms. Si vous saviez combien de commits "optimisation du code" j'ai annulé parce qu'ils obscurcissaient un code qui était aussi rapide que nécessaire...

Écrire du code performant n'a d'intérêt que lorsque l'on est certain qu'il y a (aura) un problème de performances. Dans tous les autres cas (100% du code de 95% des programmes), seuls la lisibilité et le temps de dév importent (après la conformité). C'est la base.


The First Rule of Program Optimization: Don't do it.
The Second Rule of Program Optimization (for experts only!): Don't do it yet.
source : Michael A. Jackson

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

En 1980 certainement mais pas en 2015.

En 2015 les performances dépendent presque toujours des accès mémoire et les instructions sont rarement significatives là-dedans (poids relativement plus faible, souvent en cache, grappes séquentielles). Or la structure des données est parfaitement contrôlable par le programmeur. Voir par exemple data-oriented programming.

Les seules instructions dont le temps d'exécution propre compte encore ce sont les branchements et opérations atomiques/barrières mémoires. Et tout ça est parfaitement contrôlé par le programmeur.

Enfin algorithme >> all. Un code de force brute en C sera toujours plus lent qu'un algo optimal dans un langage interprété. Et en parlant d'algo, le compilateur n'empêche certainement pas de paralléliser ! Là encore le programmeur a le contrôle.

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 ?

Dans le second cas je préfère surtout que le code soit maintenable et dénué de bogues plutôt qu'optimisé alors que ce n'est pas nécessaire. Si le code a été écrit dans les 70's où la vitesse séquentielle des CPU doublait tous les 18 mois pour une centrale devant durer trente ans...

Je suis totalement d'accord avec cette remarque
Depuis quand un code lisible et bien documenté est-il moins performant ??

Optimiser peut vouloir dire utiliser un allocateur spécifique, remplacer des pointeurs par des indices sur 2 octets, fragmenter tes objets ou dupliquer une partie de leurs fonctionnalités pour obtenir un compactage séquentiel des données nécessaires, virer les appels virtuels, virer les allocations, paralléliser, changer d'algo, changer de structure de données, réordonner les instructions, imbriquer les branchements conditionnels, etc.

Plus généralement optimiser c'est ajouter au code des contraintes additionnelles et endogènes, remplacer la mise en oeuvre naturelle par une mise en oeuvre choisie pour sa vitesse d'exécution. C'est donc presque toujours complexifier le code.

C'est un nid de frelons. Tant que tu peux l'éviter, évite-le. Et quand tu dois t'y frotter, bienvenue en enfer, camarade.

[Saverok]

En général, pour la grande majorité des programmes, écrire du code performant n'a aucun intérêt car le CPU est de toute façon cent fois plus puissant que nécessaire pour exécuter la version propre. Dans l'idéal on prend simplement le langage le plus productif qui soit et on écrit le code le plus propre le plus rapidement possible sans jamais se soucier de la performance car ça n'a aucun intérêt.

As-tu déjà bosser sur des app mobiles ?
Performance y est souvent synonyme de consommation batterie

De même, as-tu déjà bossé dans le web ?
Quand tu commences à avoir à gérer des millions de sessions et des milliers d'instructions à la seconde, les perf sont indissociables de l'expérience utilisateur et de la pérennité de la plateforme.

[DonQuiche]

As-tu déjà bosser sur des app mobiles ? De même, as-tu déjà bossé dans le web ?

Oui et aussi sur des programmes bien plus exigeants que tout cela. J'ai malheureusement une trop longue expérience de l'optimisation.

Mais j'avais écrit "la grande majorité des programmes" et je m'y tiens (avec une petite exception pour les requêtes SQL tant il est facile de faire ramer un SGBD).

[Spartacusply]

Soit on fait un code propre et le programme est performant (ou s'il ne l'est pas, ce n'est du coup pas dans la lisibilité qu'il faut le chercher).
Soit on fait du code dégueulasse et de toutes façons le code sera non-performant (ou s'il l'est, à la première maintenance vu qu'on sera obligé de faire des hooks de partout ou des trucs dans le genre, il le deviendra à ce moment là).

Après si la question c'est "faut-il faire ++i au lieu de i++ parce que c'est plus rapide bien que moins lisible ?". Euh...non, ce n'est pas avec ce genre d'optimisation que s’améliorera significativement la rapidité de votre programme.

[Saverok]

Après si la question c'est "faut-il faire ++i au lieu de i++ parce que c'est plus rapide bien que moins lisible ?". Euh...non, ce n'est pas avec ce genre d'optimisation que s’améliorera significativement la rapidité de votre programme.

Ton exemple est mal choisi car les 2 instructions ++i et i++ n'ont pas le même sens donc rien à voir avec la lisibilité
++i : on incrémente puis on évalue
i++ : on évalue puis on incrémente
Dans la plupart des cas, tu obtiendras un résultat différent

[Spartacusply]

Le i étant seul sur sa ligne bien entendu...

Ceci dit je trouve plus lisible de faire, dans le cas ou le ++i se justifierai :

Code php :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
$i = 0;
while ($i < 10) {
    $i++;
    echo '$i vaut'.$i;
}

que

Code php :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
$i = 0;
while ($i < 10) {
    echo '$i vaut'.++$i;
}

Certes, on perd une ligne, mais on gagne clairement en lisibilité.

[Bousk]

Et on en revient aux propos de CodeurPlusPlus : tu ne fais pas de code performant et n'en as pas besoin. Pouvoir écrire l'un ou l'autre est pareil pour toi, parce que les X cycles supplémentaires d'une écriture ou l'autre te sont anecdotiques. Voire inconnu.

[Luckyluke34]

Quel est le critère le plus important pour vous dans un code source ?

Ca dépend bien évidemment du contexte. Il n'y a pas de réponse universelle.

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.

[Gilliard]

C'est le type même de la mauvaise question, car incomplète :
- Logiciel embarqué, local à un PC, sur serveur ?
- Performance : Rapidité d'exécution du code / place mémoire requise / quantité d’interactions réseaux ..... ?
- Quel usage, avec quelle fréquence ?
- etc.
Ce que j'ai en revanche trop souvent constaté : Nombre de programmeurs font des choses très "belles", mais n'ont jamais vraiment réalisé ce que fait la machine , faute d'avoir été suffisamment formé tant au niveau hardware que software de bas niveau. Et la multiplicité des API ne simplifie pas le problème, on ne connaît que rarement le détail de leur fonctionnement.

[ChristianRoberge]

D'où vient cette idée imbécile qu'un code performant est illisible? Le temps où nous introduisions des instructions assembleur dans le code C est révolu depuis longtemps. Cela plus trente ans que je construit du code optimisé en C++ et mes meilleurs performances ont été avec les codes les plus lisibles et compact. J'admets qu'il faut de hautes compétences en C++ pour comprendre pourquoi les choses sont fait d'une façon plutôt qu'une autre. C'est souvent hors de la porté d'un débutant en C++ mais cela demeure très lisible et compréhensible à un excellent programmeur.
Pour expliquer mes propos je vous transmets ma question fétiche qui explique bien ce qu'implique le développement d'un code performant. La question est: Nous avons besoin d'avoir le calcul d'une factorielle. Qu'elle est le code le plus performant?
Tous cite, la fonction récursive comme le pire exemple de performance. La boucle "for" est une meilleure technique, l'index d'un vecteur précalculé est encore meilleure! La plupart des programmeurs s'arrête là et me disent que nous ne pouvons pas faire mieux! Je leur propose la solution la plus performante que je connaisse car aucun temps de calcul à l'exécution est nécessaire pour obtenir le résultat. Il s'agit de la fonction récursive classique, la moins "performante" mais programmé avec l'index d'un "Template C++". Le calcul est réalisé entièrement à la compilation. Évidemment, cette solution est limitative car elle n'a pas la flexibilité d'une fonction mais la question demandait le code le plus performant! Est-ce qu'une factorielle avec une fonction récursive "Template" est plus illisible? J'en doute. Si quelques uns seraient tenté de dire que la fonction Template est plus complexe, soit, mais la complexité provient de la syntaxe du C++ et non des concepts en jeu. Si vous trouvé toujours cela trop difficile à comprendre, le C++ et sa syntaxe ne sont pas pour vous.

[DonQuiche]

D'où vient cette idée imbécile qu'un code performant est illisible?

Comme je le disais plus haut...

Plus généralement optimiser c'est ajouter au code des contraintes additionnelles et endogènes, remplacer la mise en oeuvre naturelle par une mise en oeuvre choisie pour sa vitesse d'exécution. C'est donc presque toujours complexifier le code.

Optimiser peut vouloir dire utiliser un allocateur spécifique, remplacer des pointeurs par des indices sur 2 octets, fragmenter tes objets ou dupliquer une partie de leurs fonctionnalités pour obtenir un compactage séquentiel des données nécessaires, virer les appels virtuels, virer les allocations, paralléliser, changer d'algo, changer de structure de données, réordonner les instructions, imbriquer les branchements conditionnels, etc.

PS : il y a des façons plus sereines pour entrer dans un débat que de traiter tout avis contraire au tien d'imbécile.

[foetus]

D'où vient cette idée imbécile qu'un code performant est illisible?

J'ai un exemple ... mais je vais faire grincer les dents

Faire une machine à états avec un [gros] switch/ case (des fois c'est un double switch/ case) et des define.

Un exemple précis: tu dois manipuler un fichier XML, il n'y a que toi qui le crées, qui le parses, ...
Au lieu d'utiliser une bibliothèque comme RapidXML qui ne travaille qu'avec un buffer (avant il faut ouvrir le fichier et remplir le buffer), faire une machine à états (algo glouton) où tu ne fais qu'une seule lecture et tu supprimes toutes les fonctions callback (traitements "in place")

[cdubet]

Comme l a ecrit quelqu un juste avant moi, sur un serveur, il est souvent plus simple/moins cher de passer a une machine plus puissante que d optimiser
Par contre dans d autres cas c est impossible : vous allez pas changer le processeur de votre ABS/ESP ou meme celui du telephone. Il faut faire avec et selon le type d application, il faut repondre paridement (sinon la voiture est dans le decor)

Mais c est vrai que souvent c est que quelques parties du code qui sont critique pour la performance-> pas besoin de tout optimiser

PS: les belles architectures c est sympa, suple mais c est vrai qu au niveau temps d execution c est pas ca. On a eut le cas d un nouveau produit plus lent que l ancien meme si il est dote d un CPU bien plus moderne :-(

[frantzgac]

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

[homer242]

https://fr.wiktionary.org/wiki/au_second_degr%C3%A9

au second degré = Sans se prendre au sérieux, avec humour.

Pour en revenir au sujet, je pense qu'il faut toujours codé au plus simple puis on pourra toujours reprendre une partie si on a des contraintes de performance. Cela sous-entend bien entendu que l'on sépare correctement le code de façon à ce qu'on puisse bidouiller une partie sans tout casser...