Pourquoi les gens disent-ils que Ruby est lent? [fermé]

Tout d'Abord, plus lent par rapport à ce que? C? Python? Let's obtenir certains nombres à le Langage de l'Ordinateur Repères de Jeu:

• Ruby 1.9 vs Python3 dans le meme ordre de grandeur
• Ruby 1.9 vs PHP dans le meme ordre de grandeur
• Ruby 1.9 vs Java 6 serveur jusqu'à deux ordres de grandeur inférieur à!
• Ruby 1.9 vs C (gcc) jusqu'à deux ordres de de grandeur inférieur à!
• ...

Pourquoi Ruby est-il considéré comme lent?

Dépend de qui vous demandez. On pourrait vous dire que:

• Ruby est un langage interprété et les langages interprétés auront tendance à être plus lents que les langages compilés
• Ruby utilisegarbage collection (bien que C#, qui utilise également garbage collection, sorte deux ordres de grandeur devant Ruby, Python, PHP etc. dans le plus algorithmique, moins benchmarks gourmands en allocation de mémoire ci-dessus)
• Les appels de méthode Ruby sont lents (bien que, à cause du typage de canard, ils soient sans doute plus rapides que dans les langages interprétés fortement typés)
• Ruby (à l'exception de JRuby) ne prend pas en charge vrai multithreading
• etc.

Mais, là encore, lent par rapport à quoi? Ruby 1.9 est à peu près aussi rapide que Python et PHP (dans un facteur de performance 3x) par rapport à C (qui peut être en hausse 300x plus rapide), donc ce qui précède (à l'exception des considérations de threading, si votre application dépend fortement de cet aspect) est en grande partie académique.

Quelles sont vos options en tant que programmeur Ruby si vous voulez faire face à cette "lenteur"?

Écrivez pour l'évolutivité et lancez plus de matériel (par exemple, la mémoire)

Quelle version de Ruby conviendrait le mieux à une application comme Stack Overflow où la vitesse est critique et le trafic est intense?

Bien, REE (combiné avec Passager) serait un très bon candidat.

Voici ce que le créateur de Rails, David Heinemeier Hansson a à dire:

Rails [Ruby] est, pour la grande majorité des applications web Assez rapidement. Nous vous avez des sites qui font des millions de dynamiques pages vues par jour. Si vous vous retrouvez être avec le front Yahoo ou Amazon page, il est peu probable qu'un hors-la-étagère cadre de TOUTE la langue vous fera beaucoup de bien. Vous aurez probablement à rouler votre propre. Mais bien sûr, j'aimerais aussi des cycles CPU gratuits. Je juste arriver à l' soucie beaucoup plus cycles de développeurs gratuits et je suis prêt pour échanger le premier contre le second.

C'est-à-dire lancer plus de matériel ou de machines sur le problème est moins cher que d'embaucher plus de développeurs et d'utiliser un langage plus rapide, mais plus difficile à maintenir. Après tout, peu de gens écrivent des applications Web en C.

Ruby 1.9 est une grande amélioration par rapport à 1,8. Les plus gros problèmes avec Ruby 1.8 sont sa nature interprétée (pas de bytecode, pas de compilation) et cette méthode appelle, l'un des plus les opérations courantes en Ruby sont particulièrement lentes.

Cela n'aide pas qu'à peu près tout est une recherche de méthode dans Ruby - ajouter deux nombres, indexer un tableau. Où d'autres langages exposent des hacks (méthode __add__ de Python, méthode Perl overload.pm) Ruby fait du OO pur dans tous les cas, et cela peut nuire aux performances si le compilateur/interprète n'est pas assez intelligent.

Si j'écrivais une application Web populaire dans Ruby, je me concentrerais sur la mise en cache. La mise en cache d'une page réduit le traitement temps pour cette page à zéro, quelle que soit la langue que vous utilisez. Pour les applications Web, les frais généraux de base de données et autres E/S commencent à compter beaucoup plus que la vitesse du langage, donc je me concentrerais sur l'optimisation de cela.

L'écriture du code est lente. La lecture du code est lente. Trouver et corriger des bugs est lent. L'ajout de fonctionnalités et d'améliorations est lent. Tout ce qui améliore le précédent est une victoire. Très rarement, les performances d'exécution sont un problème.

La réponse est simple: les gens disent que ruby est lent car il est lent sur la base de comparaisons mesurées avec d'autres langues. Gardez à l'esprit, cependant, "lent" est relatif. Souvent, ruby et d'autres langues "lentes" sont assez rapides.

Joel sur le logiciel-Ruby Performance Revisited très bien explique. Peut - être obsolète cependant...

Je recommanderais de simplement m'en tenir à cela car vous êtes habitué à Ruby on Rails,
si jamais vous rencontrez un problème de performance, vous pourriez reconsidérer l'utilisation d'un langage et d'un cadre différents.

Dans ce cas, je suggérerais vraiment C # avec ASP.NET MVC 2 , fonctionne très bien pour les applications CRUD.

Je dirais que Ruby est lent car peu d'efforts ont été déployés pour rendre l'interpréteur plus rapide. Même s'applique à Python. Smalltalk est tout aussi dynamique que Ruby ou Python mais fonctionne mieux d'une magnitude, voir http://benchmarksgame.alioth.debian.org . Depuis que Smalltalk a été plus ou moins remplacé par Java et C# (c'est-à-dire il y a au moins 10 ans), plus aucun travail d'optimisation des performances n'avait été effectué pour cela et Smalltalk est toujours beaucoup plus rapide que Ruby et Python. Les gens de Xerox Parc et chez OTI / IBM avait l'argent pour payer les gens qui travaillent à rendre Smalltalk plus rapide. Ce que je ne comprends pas, c'est pourquoi Google ne dépense pas l'argent pour rendre Python plus rapide car il s'agit d'un grand magasin Python. Au lieu de cela, ils dépensent de l'argent pour le développement de langues comme Go...

Tout d'abord, vous souciez-vous de ce que les autres disent de la langue que vous aimez? Quand il fait le travail qu'il doit faire, vous allez bien.

OO n'est pas le moyen le plus rapide d'exécuter du code, mais cela aide à créer le code. Le code intelligent est toujours plus rapide que le code stupide et les boucles inutiles. Je suis un DBA et je vois beaucoup de ces boucles inutiles, je les dépose, j'utilise un meilleur code et des requêtes et l'application est plus rapide, beaucoup plus rapide. Vous souciez - vous de la dernière microseconde? Vous pourriez avoir des langues optimisées pour vitesse, d'autres font juste le travail qu'ils ont à faire et peuvent être maintenus par de nombreux programmeurs différents.

Tout est juste un choix.

Évidemment, parler de vitesse Ruby perd. Même si les tests de référence suggèrent que Ruby n'est pas tellement plus lent que PHP. Mais en retour, vous obtenez du code SEC facile à maintenir, le meilleur de tous les frameworks dans différentes langues.

Pour un petit projet, vous ne ressentirez aucune lenteur (je veux dire jusqu'à ce que

Pour un projet plus important, payer des ressources est rentable et moins cher que développeur salaires. De plus, l'écriture de code sur RoR s'avère beaucoup plus rapide que tout autre.

En 2014, cette différence de vitesse dont vous parlez est insignifiante pour la plupart des sites Web.

La façon de gérer les performances de Ruby dans l'application Web est la même qu'avec n'importe quel autre langage de programmation:

ARCHITECTURE

C'est plus facile à faire dans Rails que dans la plupart des autres frameworks Web.

Au niveau de l'application, en mettant en cache tout ce qui est censé être mis en cache et en gérant l'accès à la base de données de manière intelligente (car le goulot d'étranglement est généralement sur l'accès "DB" pour la plupart des applications WEB).

Rails le rend très facile et naturelle pour résoudre ces problèmes. Il y a plusieurs abstractions pour mettre en cache des données, des pages et des fragments, et il y a aussi de très belles abstractions pour traiter la partie SQL de manière optimisée et réutilisable ( Active Recordet AREL).

C'est la raison pour laquelle tant d'applications écrites dans des langages plus rapides et moins expressifs (comme php) finissent par être plus lentes que les homologues Ruby. Ce n'est pas si facile et élégant de s'attaquer à la mise en cache et à l'interrogation avec ces langues qu'il est avec Ruby.

Au niveau de l'infrastructure , il est raisonnable de penser à l'équilibrage de charge et à toutes ces choses que je ne connais pas beaucoup. J'externaliserais ce problème en embauchant une plate-forme en tant que fournisseur de services, comme Heroku ou Engine Yard. De toute façon. Déployer des rails avec équilibrage de charge n'est probablement pas très difficile à faire.

Ruby est plus lent que C++ pour un certain nombre de tâches facilement mesurables (par exemple, faire du code qui dépend fortement de la virgule flottante). Ce n'est pas très surprenant, mais une justification suffisante pour que certaines personnes disent que "Ruby est lent" sans qualification. Ils ne comptent pas le fait qu'il est beaucoup plus facile et plus sûr d'écrire du code Ruby que C++.

La meilleure solution consiste à utiliser des modules ciblés écrits dans un autre langage (par exemple, C, C++, Fortran) dans votre code Ruby. Ceux-ci peuvent faire le levage lourd et vos scripts peuvent se concentrer sur des problèmes de coordination de niveau supérieur.

La performance est presque toujours une bonne conception et des interactions de base de données optimisées. Ruby fait ce que la plupart des sites Web ont besoin assez rapide, en particulier les versions plus récentes; et la vitesse de développement et la facilité de maintenance fournit un gain important en coûts et en gardant les clients heureux. Je trouve que JAVA a des performances d'exécution lentes pour certaines tâches, et compte tenu de la difficulté de développement en JAVA, de nombreux développeurs créent des applications lentes indépendamment de la capacité de vitesse théorique comme démontré dans les repères (les repères sont généralement conçus pour montrer une capacité spécifique et étroite). Lorsque j'ai besoin d'un traitement intensif qui ne convient pas aux capacités de ma base de données, je choisis C ou Objective-C ou un autre langage compilé vraiment performant pour ces tâches en fonction de la plate-forme. Si j'ai besoin de créer une application Web basée sur des données, j'utilise RoR ou parfois C# ASP.NET en fonction d'autres exigences; parce que toutes les plates-formes ont des forces et des faiblesses. Exécution la vitesse des choses que votre application fait est importante, mais après tout, si les performances d'exécution d'un aspect étroit d'un langage sont tout ce qui compte; alors je pourrais toujours utiliser le langage Assembleur pour tout.

Les gens disent que Ruby est lent parce qu'ils comparent les programmes Ruby aux programmes écrits dans d'autres langues. Peut-être que les programmes que vous écrivez n'ont pas besoin d'être plus rapides. Peut-être que pour les programmes que vous écrivez, Ruby n'est pas le goulot d'étranglement qui ralentit les choses.

Ruby 2.1 par rapport à Javascript V8

Ruby 2.1 comparé au Lua ordinaire

Ruby 2.1 par rapport à Python 3

Rubis fonctionne bien pour la productivité des développeurs. Ruby par nature force le développement piloté par les tests en raison du manque de types. Ruby fonctionne bien lorsqu'il est utilisé comme wrapper de haut niveau pour les bibliothèques C. Ruby fonctionne également bien pendant les processus de longue durée lorsqu'il est compilé en JIT en code machine via JVM ou Rbx VM. Ruby ne fonctionne pas bien quand il est nécessaire de croquer des nombres en peu de temps avec du code ruby pur.