Joel Spolsky a lancé un gros troll sur les performances de Ruby et s'est attiré plusieurs réponses cinglantes:

  1. Sur la différence entre efficacité et montée en charge.
  2. Sur la possibilité d'optimiser la VML de Ruby.
  3. Sur le fait que Ryby n'est pas fait pour les performances CPU.

Le dernier point développé est à mon avis le plus important et je l'avais déjà vu, il me semble, dans les essais de Paul Graham.

  1. Dans l'écriture d'un logiciel, ce qui coûte le plus cher, ce n'est pas les cycles processeurs mais les cycles développeurs. Donc il est extrêmement utile d'avoir des outils qui favorisent grandement les performances des développeurs comme Ruby.
  2. 90% du code n'a rien à voir avec les performances, c'est juste de l'enrobage pour faire fonctionner tout le bastringue.
  3. Sur les 10% restant 90% peut être optimisé par des méthodes algorithmiques (pour un classique voir l'optimisation du calcul de la suite de fibonnaci).
  4. Sur le 1% restant, les langages de haut niveau offre généralement (sinon ils sont inutiles) de pouvoir utiliser des systèmes de plus bas niveau (C ou ligne de commande). Pour améliorer les fonctions qui sont gourmandes en calcul, il suffit donc de les implémenter en C voir en assembleur si on tient vraiement à faire de l'optimisation de bourrin. C'est ce que font Yahoo, Amazon, Google et les autres avec des frameworks de présentation web Java, PHP, PERL et des bibilothèques optimisées en C++.

Donc moralité de l'histoire:

  1. Ne pas chercher à optimiser tout de suite, mais à développer les fonctionnalités.
  2. Utiliser le langage le plus productif pour les développements et non le plus performant pour le processeur.
  3. Une fois identifié les goulots d'étranglement, les optimiser en les codants dans un langage performant ce qui se résume à du C ou du C++, voir de l'assembleur pour les brutes.