IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

47PARTAGES

3  12 
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 ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de 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...
13  0 
Avatar de 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.
13  1 
Avatar de AoCannaille
Expert confirmé 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.
10  1 
Avatar de 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
8  0 
Avatar de 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
6  0 
Avatar de 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.
6  0 
Avatar de 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.
5  0 
Avatar de gangsoleil
Modérateur https://www.developpez.com
Le 26/09/2013 à 10:17
J'ai tout de meme un doute si on prend tout en compte :
Stackoverflow ne vit que parce qu'il est en ligne, et ne peut se permettre de s'arreter. Donc il faut de la haute disponibilite, et au moins un site de backup.

Bien sur, on peut ameliorer en permanence le materiel du site principal [en supposant qu'il n'y en ait qu'un], et laisser l'autre avec des pentium3... Mais si on veut un vrai site de backup, il faut aussi l'upgrader.
Et les deux sites doivent etre alimentes en electricite et en ligne internet. Or arrive un moment ou problematique ou il faut changer la clim et/ou la ligne electrique et/ou pousser les murs pour mettre les nouveaux serveurs.
Je n'ai pas encore compte le cout des logiciels de haute-disponibilite, de la maintenance admin et reseau, ...

Bref, si on compare "juste" le salaire d'un bon developpeur experimente sur un an a ce qu'on peut acheter comme hardware pour ce prix la, c'est certain que c'est un calcul en faveur du hard. Mais avec une telle comparaison, il faut peut-etre aussi se remettre un peu en question.
5  0 
Avatar de Washmid
Membre averti 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.
4  0 
Avatar de Niark13
Membre éclairé https://www.developpez.com
Le 25/09/2013 à 17:30
Je crains que son avis, qui a déjà plusieurs années, ne tienne pas la distance vis à vis de la fin de la loi de Moore ainsi que la crise énergétique et le changement de paradigme qu'elle impose…
4  0