Faut-il investir dans l'optimisation du code ou les équipements ?
Pour un blogueur de nouvelles machines produiront un meilleur résultat

Le , par Cedric Chevalier, Expert éminent sénior
Si vous deviez améliorer les performances d’une application, opteriez-vous pour l’optimisation du code ou pour l’achat de nouveaux appareils puissants ? Pour Jeff Atwood, créateur du site StackOverflow, la question ne devrait même pas se poser.

Selon celui-ci, les programmeurs coûtent excessivement cher alors que les périphériques puissants comme les serveurs le sont moins. D’après Jeff Atwood, la paie mensuelle du plus modeste des programmeurs aux États-Unis lui a permis d’acheter deux serveurs puissants, ainsi qu’un disque de sauvegarde sans compter les unités redondantes de disques pour StackOverflow.

D’après Jeff, les gains de performances et de productivité réalisés avec l’achat de ce matériel haut de gamme se sont faits rapidement ressentir. Autrement dit, avec un bon matériel, l’amélioration des performances suit toujours. Cependant, même en embauchant des programmeurs qu’elle paye modestement, une entreprise court un risque énorme.

La probabilité que la productivité de ces programmeurs soit faible de façon à ce que la firme n’ait pas un retour sur investissement conséquent dans le temps est élevée. Jeff dit d’ailleurs qu’il comprend maintenant les entreprises qui mettent constamment leurs programmeurs sous pression.

Par contre, il reconnaît que la machine seule ne suffit pas. Un programmeur expert devra se charger de produire du code optimisé pour le matériel haut de gamme, de façon à tirer pleinement parti de la totalité de sa puissance.

Une fois encore, il met en garde. Déjà que ces programmeurs experts coûteront horriblement cher, l’optimisation est une pratique déconseillée, voire même dangereuse. Il cite M.A Jackson qui donne des règles d’or sur l’optimisation du code « Règle 1: Ne jamais l’utiliser. Règle 2: Si vous êtes expert, ne l’utilisez pas maintenant. »

Autrement dit, Jeff conseille encore une fois d’utiliser les performances de calcul des nouveaux périphériques au profit d’investissements dans du code optimisé.

Source : Coding Horror

Et vous ?

Que pensez-vous du point de vue de Jeff Atwood ?

Et si vous aviez le choix entre optimiser le code et améliorer les performances via les équipements, que choisiriez-vous ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de el_slapper el_slapper - Expert éminent sénior https://www.developpez.com
le 25/09/2013 à 14:27
Il a quelques années, son article. J'ai du le mettre en lien deux ou trois fois dans le coin.....

Et surtout, l'article original dit qu'on ferait mieux de mettre du matos sur les problèmes de performances pour utiliser les programmeurs à faire de la valeur ajoutée, pas à virer tous les programmeurs.

On est pas vendredi, pourtant...
Avatar de Paul TOTH Paul TOTH - Expert éminent sénior https://www.developpez.com
le 25/09/2013 à 14:36
sur la question des performances c'est peut-être pas faux...acheter une machine suffisamment puissante pour faire tourner une appli c'est une quantité mesurable, le temps que mettra le développeur pour rendre l'application plus véloce sur la machine existante l'est moins.

par contre, du point de vu fiabilité, la plus puissante des machines ne corrigera jamais les bugs toute seule
Avatar de gros_rougeot gros_rougeot - Membre du Club https://www.developpez.com
le 25/09/2013 à 16:36
Malheureusement il a raison.

Conséquences : trop de logiciel récents et grands publics rament sur de vieilles bécanes alors qu'ils n'ont pas plus de fonctionnalités que leurs anciennes versions.
Avatar de AoCannaille AoCannaille - Membre expérimenté https://www.developpez.com
le 25/09/2013 à 16:38
Si je me souviens bien de mes cours d'algo d'IUT, en particulier de ceux sur la compléxité, il me semble que passer un algo de n^3 à nlog(n) permettait de faire passer des calculs d'un an à quelques minutes.

Il faut cibler le niveau d'optim. Optimiser des variables intermédiaires, un passage de boucle par-ci par là avec while/do while ça ne vaut effectivement probablement pas le coup. En particulier si l'algo devient moins clair donc moins maintenable.

Par contre, l'optim' basique des algos reste en ce sens indispensable.

de mémoire Knuth disait que les étapes dans l’algorithmique c'était :
1. On écrit un algo naïf qui répond aux exigences fonctionnelles
2. on l'optimise
3. on le rend "propre" et maintenable (nom de variable, indentation, commentaires etc...)

pour moi, en résumé:
L'optimisation du code à la conception reste indispensable.
L'optimisation du code en production, pour un delta inférieur à n² peut être résolu en changeant de matos.
Avatar de Washmid Washmid - Membre actif https://www.developpez.com
le 25/09/2013 à 16:51
C'est pas toujours vrai. Dans ma boite, sur du matériel mobile, on a eu un investissement d'un million d'euros rien que le matériel (ajoutez à ça les frais annexes) pour une appli sur laquelle bosse un dev et demie.

Suite à des problèmes de performances justement, on a eu le choix entre réinvestir à nouveau dans du matériel ou mettre un dev sur l'optimisation de code pendant 6 mois... Le calcul est vite fait.
Avatar de germinolegrand germinolegrand - Membre expert https://www.developpez.com
le 25/09/2013 à 16:52
Visiblement pour FB, ça coûte nettement moins cher d'investir dans l'optimisation (et ils emploient des experts -cher- et pas des moindres !) que dans les machines comme nous le précise Andrei Alexandrescu récemment .

remarque de JolyLoic à ce sujet
Avatar de Sirus64 Sirus64 - Membre éclairé https://www.developpez.com
le 25/09/2013 à 16:54
Que pensez-vous du point de vue de Jeff Atwood ?
Il a tord et raison. Il a tord car il faut d'abord trouver le goulot d'étranglement. Il a raison dans le sens ou changer le code n'apporte pas le retour sur investissement.

Et si vous aviez le choix entre optimiser le code et améliorer les performances via les équipements, que choisiriez-vous ?
En dev, on cherche à optimiser un minimum dans un temps raisonnable (ie. dans le temps alloué pour créer cette partie du projet).
En production, on commence par faire des analyses de performances et on réhausse les serveurs ou on ajoute des serveurs avant d'ouvrir le code (c'est aussi plus rapide à faire qu'analyser le code....)
Avatar de kolodz kolodz - Modérateur https://www.developpez.com
le 25/09/2013 à 17:05
Le propos se résume plus à ces étapes :

  1. Throw cheap, faster hardware at the performance problem.
  2. If the application now meets your performance goals, stop.
  3. Benchmark your code to identify specifically where the performance problems are.
  4. Analyze and optimize the areas that you identified in the previous step.
  5. If the application now meets your performance goals, stop.
  6. Go to step 1.

Pour les développeurs que je connais, ceux-ci ont déjà des machines relativement puissante à leur disposition pour leur développement. Dans un cas d'une application d'entreprise, il est certes plus facile d'acheter un second serveur.

M.A Jackson qui donne des règles d’or sur l’optimisation du code « Règle 1: Ne jamais l’utiliser. Règle 2: Si vous êtes expert, ne l’utilisez pas maintenant. »

Cela me fait penser à deux exemples vue dans une application :
1. Le cache plus lent que le calcul des données qu'il met en cache.
2. L'algorithme qui remplace la bonne requête sur base de donnée.

Cette règle d'or s'applique directement au premier cas. Mais pour le second, je considère la mise en place de la bonne requête est une optimisation en plus d'être une règle de codage.

Pour moi une application lente est une application mal codé. Mettre une machine plus puissante, c'est comme mettre plus d'essence dans une voiture qui à le réservoir percé. Ça va bien pour faire les 10 bornes pour rentrer chez soit le vendredi soir.

Cordialement,
Patrick Kolodziejczyk.
Avatar de grunk grunk - Modérateur https://www.developpez.com
le 25/09/2013 à 17:07
Citation Envoyé par germinolegrand  Voir le message
Visiblement pour FB, ça coûte nettement moins cher d'investir dans l'optimisation (et ils emploient des experts -cher- et pas des moindres !) que dans les machines comme nous le précise Andrei Alexandrescu récemment .

Quand une update materiel implique plusieurs centaines voir milliers de serveur effectivement , la réflexion doit être différente.
Avatar de Squisqui Squisqui - En attente de confirmation mail https://www.developpez.com
le 25/09/2013 à 17:08
L'éternel débat entre la loi de Moore et la loi de Wirth
Malgré que les deux ont su prouver leur véracité pendant des années, aujourd'hui, la première montre ses limites favorisant à violer la seconde sur certains domaines.

Le jugement de Jeff Atwood était sans doute bon en 2008, mais il est bien connu que seuls les imbéciles ne changent pas d'avis. Nous sommes bientôt en 2014, les choses ont beaucoup changées et il est peut-être temps de se remettre en question.
Certains ont déjà commencé avec Microsoft qui optimise son OS Windows depuis Vista ou encore les différents développeurs autour des moteurs JavaScript.
Comble de l'ironie, les smartphones/tablettes utilisent du matériel beaucoup plus puissant qu'il y a 5ans sans en faire beaucoup plus.
Offres d'emploi IT
Ingénieur développement fpga (traitement vidéo) H/F
Safran - Ile de France - 100 rue de Paris 91300 MASSY
Architecte technique des systèmes d'information H/F
Safran - Ile de France - Évry (91090)
Chef projet big data - pse flotte H/F
Safran - Ile de France - Évry (91090)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil