J'aime Ruby on Rails et je l'utilise pour tous mes projets de développement web. Il y a quelques années, on parlait beaucoup du fait que Rails était un porc de mémoire et du fait qu'il ne s'adaptait pas très bien, mais ces suggestions ont été mises au lit par Gregg Pollack. ici .
Dernièrement cependant, j'ai entendu des gens dire que Ruby lui-même était lent.
- Pourquoi Ruby est-il considéré comme lent?
Je ne trouve pas que Ruby soit lent, mais encore une fois, je l'utilise simplement pour créer de simples applications CRUD et des blogs d'entreprise. Quels types de projets aurais-je besoin de faire avant de trouver Ruby en train de devenir lent? Ou est-ce que cette lenteur est quelque chose qui affecte tous les langages de programmation?
Quelles sont vos options en tant que programmeur Ruby si vous voulez faire face à cette «lenteur»?
Quelle version de Ruby conviendrait le mieux à une application comme Stack Overflow où la vitesse est critique et le trafic intense?
Les questions sont subjectives et je me rends compte que la configuration architecturale (EC2 vs serveurs autonomes, etc.) fait une grande différence mais j'aimerais entendre ce que les gens pensent de la lenteur de Ruby.
Enfin, je ne trouve pas beaucoup de nouvelles sur Ruby 2.0 - je suppose que nous sommes à quelques années de cela alors?
la source
Réponses:
Parce que si vous exécutez des benchmarks typiques entre Ruby et d'autres langages, Ruby perd.
Ruby ne vous servirait probablement pas bien pour écrire une application de traitement du signal numérique en temps réel ou tout autre système de contrôle en temps réel. Ruby (avec les machines virtuelles d'aujourd'hui) s'étoufferait probablement sur un ordinateur aux ressources limitées comme les smartphones.
N'oubliez pas qu'une grande partie du traitement de vos applications Web est en fait effectuée par des logiciels développés en C. par exemple Apache, Thin, Nginx, SQLite, MySQL, PostgreSQL, de nombreuses bibliothèques d'analyse, RMagick, TCP / IP, etc. sont des programmes C utilisés par Ruby . Ruby fournit la colle et la logique métier.
Passez à une langue plus rapide. Mais cela a un coût. C'est un coût qui peut en valoir la peine. Mais pour la plupart des applications Web, le choix de la langue n'est pas un facteur pertinent car il n'y a tout simplement pas assez de trafic pour justifier l'utilisation d'un langage plus rapide qui coûte beaucoup plus cher à développer.
D'autres personnes ont répondu à cela - JRuby, IronRuby, REE rendront la partie Ruby de votre application plus rapide sur des plates-formes qui peuvent se permettre les machines virtuelles. Et comme ce n'est souvent pas Ruby qui cause la lenteur, mais l'architecture de votre système informatique et l'architecture de vos applications, vous pouvez faire des choses comme la réplication de base de données, plusieurs serveurs d'applications, l'équilibrage de charge avec des proxys inverses, la mise en cache HTTP, Memcache, Ajax, la mise en cache côté client, etc. Aucun de ces trucs n'est Ruby.
La plupart des gens attendent Ruby 1.9.1. J'attends moi-même Rails 3.1 sur Ruby 1.9.1 sur JRuby.
Enfin, rappelez-vous que de nombreux développeurs choisissent Ruby parce que cela rend la programmation plus agréable par rapport à d'autres langages, et parce que Ruby with Rails permet aux développeurs Web qualifiés de développer des applications très rapidement.
la source
Tout d'abord, plus lent par rapport à quoi ? C? Python? Prenons quelques chiffres au jeu des benchmarks du langage informatique :
Cela dépend de qui vous demandez. On pourrait vous dire que:
Mais, là encore, lent par rapport à quoi? Ruby 1.9 est à peu près aussi rapide que Python et PHP (avec un facteur de performance 3x) par rapport à C (qui peut être jusqu'à 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 ) sont largement académiques.
Écrire pour l'évolutivité et y ajouter plus de matériel (par exemple, de la mémoire)
Eh bien, REE (combiné avec Passenger ) serait un très bon candidat.
la source
Voici ce que le créateur de Rails, David Heinemeier Hansson a à dire:
c'est-à-dire que lancer plus de matériel ou de machines au 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 amélioration considérable 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 que les appels de méthode, l'une des opérations les plus courantes de Ruby, sont particulièrement lents.
Cela n'aide pas que presque tout soit une recherche de méthode dans Ruby - ajouter deux nombres, indexer un tableau. Là où d'autres langages exposent des hacks (
__add__méthode de Python , overload.pm de Perl) Ruby fait de la pure OO dans tous les cas, et cela peut nuire aux performances si le compilateur / interpréteur n'est pas assez intelligent.Si j'écrivais une application Web populaire en Ruby, je me concentrerais sur la mise en cache. La mise en cache d'une page réduit le temps de traitement de cette page à zéro, quelle que soit la langue que vous utilisez. Pour les applications Web, la surcharge de la base de données et les autres E / S commencent à avoir beaucoup plus d'importance que la vitesse du langage, je me concentrerais donc sur l'optimisation de cela.
la source
L'écriture du code est lente. La lecture du code est lente. Trouver et corriger les bogues 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. Les performances d'exécution sont très rarement un problème.
la source
La réponse est simple: les gens disent que le rubis est lent parce qu'il est lent basé sur des comparaisons mesurées avec d'autres langues. Gardez à l'esprit, cependant, que «lent» est relatif. Souvent, le rubis et les autres langages «lents» sont assez rapides.
la source
Joel on Software - Ruby Performance Revisited l' explique assez bien. Pourrait être obsolète cependant ...
Je recommanderais de vous en tenir à cela car vous êtes habitué à Ruby on Rails,
si jamais vous rencontrez un problème de performances, vous pouvez reconsidérer pour utiliser un langage et 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.
la source
Je dirais que Ruby est lent car peu d'efforts ont été consacrés à rendre l'interprète plus rapide. La même chose s'applique à Python. Smalltalk est tout aussi dynamique que Ruby ou Python mais fonctionne mieux de loin, voir http://benchmarksgame.alioth.debian.org . Depuis Smalltalk a été plus ou moins remplacé par Java et C # (c'est-à-dire il y a au moins 10 ans), aucun travail d'optimisation des performances n'a été effectué pour lui et Smalltalk est toujours bien plus rapide que Ruby et Python. Les gens de Xerox Parc et d'OTI / IBM avaient l'argent pour payer ceux 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'une grande boutique Python. Au lieu de cela, ils dépensent de l'argent pour développer des langages comme Go ...
la source
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, tout va bien.
OO n'est pas le moyen le plus rapide d'exécuter du code, mais il 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 vois beaucoup de ces boucles inutiles, supprimez-les, utilisez 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 pouvez avoir des langages optimisés pour la vitesse, d'autres font juste le travail qu'ils ont à faire et peuvent être maintenus par de nombreux programmeurs différents.
C'est juste un choix.
la source
De toute évidence, parler de vitesse perd Ruby. 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 un code DRY facile à entretenir, le meilleur de tous les frameworks dans différentes langues.
Pour un petit projet, vous ne ressentirez aucune lenteur (je veux dire jusqu'à <50K utilisateurs) étant donné qu'aucun calcul complexe n'est utilisé dans le code, juste les choses courantes.
Pour un projet plus important, payer les ressources est payant et coûte moins cher que les salaires des développeurs. De plus, l'écriture de code sur RoR s'avère beaucoup plus rapide que tout autre.
En 2014, l'ampleur de la différence de vitesse dont vous parlez est insignifiante pour la plupart des sites Web.
la source
La manière de gérer les performances de Ruby dans une application Web est la même que pour tout 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 (puisque le goulot d'étranglement se situe généralement sur l'accès «DB» pour la plupart des applications WEB).
Grâce aux rails, il est très facile et naturel de résoudre ces problèmes. Il existe plusieurs abstractions pour la mise 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 Record et 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. Il n'est pas si facile et élégant de s'attaquer à la mise en cache et aux requêtes avec ces langages qu'avec Ruby.
Au niveau de l'infrastructure, il est raisonnable de penser à l'équilibrage de charge et à tout ce 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 . En tous cas. Le déploiement de rails avec équilibrage de charge n'est probablement pas très difficile à faire.
la source
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 certains disent que «Ruby est lent» sans réserve. Ils ne tiennent pas compte du 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 gros du travail et vos scripts peuvent se concentrer sur des problèmes de coordination de niveau supérieur.
la source
La performance repose presque toujours sur une bonne conception et des interactions de base de données optimisées. Ruby fait ce dont la plupart des sites Web ont besoin assez rapidement, en particulier les versions les plus récentes; et la rapidité du développement et la facilité de maintenance offrent un gain important en termes de coûts et de satisfaction des clients. Je trouve que JAVA a des performances d'exécution lentes pour certaines tâches, et étant donné la difficulté de développement en JAVA, de nombreux développeurs créent des applications lentes quelle que soit la capacité de vitesse théorique démontrée dans les benchmarks (les benchmarks sont généralement conçus pour montrer une capacité spécifique et étroite). Lorsque j'ai besoin d'un traitement intensif qui n'est pas bien adapté aux capacités de ma base de données, je choisis C ou Objective-C ou un autre langage compilé vraiment haute performance 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; car toutes les plateformes ont des forces et des faiblesses. La vitesse d'exécution des tâches de votre application 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 encore utiliser le langage Assembler pour tout.
la source
Les gens disent que Ruby est lent car 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 par rapport au Lua ordinaire
Ruby 2.1 par rapport à Python 3
la source
Ruby 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 lorsqu'il est nécessaire de traiter des nombres en peu de temps avec du code ruby pur.
la source