¿Por qué la gente dice que Ruby es lento? [cerrado]

Me gusta Ruby on Rails y lo uso para todos mis proyectos de desarrollo web. Hace algunos años hubo un montón de hablar de los carriles de ser un cerdo de la memoria y sobre la forma en que no escala muy bien, pero estas sugerencias se pusieron a la cama por Gregg Pollack aquí .

Últimamente, he estado escuchando a personas decir que Ruby es lento.

• ¿Por qué Ruby se considera lento?

No creo que Ruby sea lento, pero de nuevo, solo lo estoy usando para hacer aplicaciones CRUD simples y blogs de la compañía. ¿Qué tipo de proyectos necesitaría hacer antes de que Ruby se vuelva lento? ¿O es esta lentitud algo que afecta a todos los lenguajes de programación?

• ¿Cuáles son sus opciones como programador de Ruby si quiere lidiar con esta "lentitud"?

• ¿Qué versión de Ruby se adapta mejor a una aplicación como Stack Overflow donde la velocidad es crítica y el tráfico es intenso?

Las preguntas son subjetivas, y me doy cuenta de que la configuración arquitectónica (EC2 frente a servidores independientes, etc.) hace una gran diferencia, pero me gustaría escuchar lo que la gente piensa acerca de que Ruby es lento.

Finalmente, no puedo encontrar muchas noticias sobre Ruby 2.0. ¿Supongo que estamos a unos pocos años de eso?

¿Por qué Ruby se considera lento?

Porque si ejecuta puntos de referencia típicos entre Ruby y otros idiomas, Ruby pierde.

No creo que Ruby sea lento, pero de nuevo, solo lo estoy usando para hacer aplicaciones CRUD simples y blogs de la compañía. ¿Qué tipo de proyectos necesitaría hacer antes de que Ruby se vuelva lento? ¿O es esta lentitud algo que afecta a todos los lenguajes de programación?

Ruby probablemente no le sirva para escribir una aplicación de procesamiento de señal digital en tiempo real, o cualquier tipo de sistema de control en tiempo real. Ruby (con las máquinas virtuales de hoy) probablemente se atragantaría con una computadora con recursos limitados como los teléfonos inteligentes.

Recuerde que gran parte del procesamiento en sus aplicaciones web en realidad se realiza mediante software desarrollado en C. por ejemplo, Apache, Thin, Nginx, SQLite, MySQL, PostgreSQL, muchas bibliotecas de análisis, RMagick, TCP / IP, etc. son programas en C utilizados por Ruby . Ruby proporciona el pegamento y la lógica empresarial.

¿Cuáles son sus opciones como programador de Ruby si quiere lidiar con esta "lentitud"?

Cambia a un idioma más rápido. Pero eso tiene un costo. Es un costo que puede valer la pena. Pero para la mayoría de las aplicaciones web, la elección del idioma no es un factor relevante porque simplemente no hay suficiente tráfico para justificar el uso de un lenguaje más rápido que cuesta mucho más desarrollar.

¿Qué versión de Ruby se adapta mejor a una aplicación como Stack Overflow donde la velocidad es crítica y el tráfico es intenso?

Otras personas han respondido esto: JRuby, IronRuby, REE harán que la parte Ruby de su aplicación se ejecute más rápido en plataformas que pueden permitirse las máquinas virtuales. Y como a menudo no es Ruby lo que causa la lentitud, sino la arquitectura de su sistema informático y la arquitectura de la aplicación, puede hacer cosas como la replicación de bases de datos, múltiples servidores de aplicaciones, equilibrio de carga con servidores proxy inversos, almacenamiento en caché HTTP, memcache, Ajax, almacenamiento en caché del lado del cliente, etc. Ninguna de estas cosas es Ruby.

Finalmente, no puedo encontrar muchas noticias sobre Ruby 2.0. ¿Supongo que estamos a unos pocos años de eso?

La mayoría de la gente está esperando a Ruby 1.9.1. Yo mismo estoy esperando Rails 3.1 en Ruby 1.9.1 en JRuby.

Finalmente, recuerde que muchos desarrolladores eligen Ruby porque hace que la programación sea una experiencia más alegre en comparación con otros lenguajes, y porque Ruby con Rails permite a los desarrolladores web expertos desarrollar aplicaciones muy rápidamente.

En primer lugar, ¿ más lento con respecto a qué ? ¿C? ¿Pitón? Vamos a obtener algunos números en el juego de pruebas de lenguaje de computadora :

• Ruby 1.9 vs. Python3 dentro del mismo orden de magnitud
• Ruby 1.9 vs. PHP dentro del mismo orden de magnitud
• ¡Ruby 1.9 vs. servidor Java 6 hasta dos órdenes de magnitud más lento !
• ¡Ruby 1.9 vs. C (gcc) hasta dos órdenes de magnitud más lento !
• ...

¿Por qué Ruby se considera lento?

Depende de a quién le preguntes. Se te podría decir que:

• Ruby es un lenguaje interpretado y los idiomas interpretados tenderán a ser más lentos que los compilados.
• Ruby usa recolección de basura (aunque C #, que también usa recolección de basura, sale dos órdenes de magnitud por delante de Ruby, Python, PHP, etc. en los puntos de referencia más algorítmicos y con menos asignación de memoria anteriores)
• Las llamadas al método de Ruby son lentas (aunque, debido a la escritura de pato, son posiblemente más rápidas que en los idiomas interpretados fuertemente tipados)
• Ruby (con la excepción de JRuby) no admite multiprocesamiento verdadero
• etc.

Pero, de nuevo, ¿lento con respecto a qué? Ruby 1.9 es casi tan rápido como Python y PHP (dentro de un factor de rendimiento 3x) en comparación con C (que puede ser hasta 300x más rápido), por lo que lo anterior (con la excepción de las consideraciones de subprocesos, si su aplicación depende en gran medida de este aspecto ) son en gran parte académicos.

¿Cuáles son sus opciones como programador de Ruby si quiere lidiar con esta "lentitud"?

Escriba para la escalabilidad y arroje más hardware (por ejemplo, memoria)

¿Qué versión de Ruby se adapta mejor a una aplicación como Stack Overflow donde la velocidad es crítica y el tráfico es intenso?

Bueno, REE (combinado con Pasajero ) sería un muy buen candidato.

Esto es lo que el creador de Rails, David Heinemeier Hansson, tiene que decir:

Rails [Ruby] es para la gran mayoría de las aplicaciones web Fast Enough. Tenemos sitios que realizan millones de visitas dinámicas por día. Si terminas en la página principal de Yahoo o Amazon, es poco probable que un marco fuera de la plataforma en CUALQUIER idioma te haga mucho bien. Probablemente tendrás que rodar el tuyo. Pero claro, también me gustaría tener ciclos de CPU gratuitos. Simplemente me preocupo mucho más por los ciclos de desarrollo gratuitos y estoy dispuesto a cambiar el primero por el segundo.

es decir, lanzar más hardware o máquinas al problema es más barato que contratar más desarrolladores y usar un lenguaje más rápido, pero más difícil de mantener. Después de todo, pocas personas escriben aplicaciones web en C.

Ruby 1.9 es una gran mejora con respecto a 1.8. Los mayores problemas con Ruby 1.8 son su naturaleza interpretada (sin bytecode, sin compilación) y las llamadas a métodos, una de las operaciones más comunes en Ruby, son particularmente lentas.

No ayuda que casi todo sea una búsqueda de métodos en Ruby: agregar dos números e indexar una matriz. Donde otros lenguajes exponen hacks ( __add__método de Python , Perl's overload.pm) Ruby hace OO puro en todos los casos, y esto puede dañar el rendimiento si el compilador / intérprete no es lo suficientemente inteligente.

Si estuviera escribiendo una aplicación web popular en Ruby, mi enfoque estaría en el almacenamiento en caché. El almacenamiento en caché de una página reduce el tiempo de procesamiento para esa página a cero, independientemente del idioma que esté utilizando. Para las aplicaciones web, la sobrecarga de la base de datos y otras E / S comienzan a importar mucho más que la velocidad del lenguaje, por lo que me enfocaría en optimizar eso.

Escribir código es lento. La lectura del código es lenta. Encontrar y corregir errores es lento. Agregar funciones y mejoras es lento. Cualquier cosa que mejore con respecto al anterior es una victoria. Muy raramente el rendimiento de ejecución es un problema.

La respuesta es simple: la gente dice que el rubí es lento porque es lento en base a comparaciones medidas con otros idiomas. Tenga en cuenta, sin embargo, que "lento" es relativo. A menudo, ruby ​​y otros idiomas "lentos" son lo suficientemente rápidos.

Joel sobre software: Ruby Performance Revisited lo explica muy bien. Aunque podría estar desactualizado ...

Recomendaría seguir con él, ya que está acostumbrado a Ruby on Rails,
si alguna vez encuentra un problema de rendimiento, podría reconsiderar usar un lenguaje y un marco diferentes.

En ese caso, realmente sugeriría C # con ASP.NET MVC 2 , funciona muy bien para aplicaciones CRUD.

Diría que Ruby es lento porque no se ha dedicado mucho esfuerzo a hacer que el intérprete sea más rápido. Lo mismo se aplica a Python. Smalltalk es tan dinámico como Ruby o Python, pero funciona mejor en una magnitud, consulte http://benchmarksgame.alioth.debian.org . Dado que Smalltalk fue más o menos reemplazado por Java y C # (es decir, hace al menos 10 años), no se ha realizado más trabajo de optimización de rendimiento y Smalltalk sigue siendo mucho más rápido que Ruby y Python. Las personas en Xerox Parc y en OTI / IBM tenían el dinero para pagar a las personas que trabajan para hacer que Smalltalk sea más rápido. Lo que no entiendo es por qué Google no gasta el dinero para hacer que Python sea más rápido, ya que son una gran tienda de Python. En cambio, gastan dinero en el desarrollo de lenguajes como Go ...

En primer lugar, ¿te importa lo que otros digan sobre el idioma que te gusta? Cuando hace el trabajo que tiene que hacer, estás bien.

OO no es la forma más rápida de ejecutar código, pero ayuda a crear el código. El código inteligente siempre es más rápido que el código tonto y los bucles inútiles. Soy un administrador de bases de datos y veo muchos de estos bucles inútiles, los descarto, utilizo mejores códigos y consultas y la aplicación es más rápida, mucho más rápida. ¿Te importa el último microsegundo? Es posible que tenga idiomas optimizados para la velocidad, otros simplemente hacen el trabajo que tienen que hacer y pueden ser mantenidos por muchos programadores diferentes.

Todo es solo una elección.

Obviamente, hablando de velocidad, Ruby pierde. Aunque las pruebas de referencia sugieren que Ruby no es mucho más lento que PHP. Pero a cambio, está obteniendo un código DRY fácil de mantener, el mejor de todos los marcos en varios idiomas.

Para un proyecto pequeño, no sentirá ninguna lentitud (es decir, hasta <50K usuarios) dado que no se utilizan cálculos complejos en el código, solo las cosas principales.

Para un proyecto más grande, pagar por los recursos vale la pena y es más barato que los salarios de los desarrolladores. Además, escribir código en RoR resulta ser mucho más rápido que cualquier otro.

En 2014, esta magnitud de diferencia de velocidad de la que habla es insignificante para la mayoría de los sitios web.

La forma de lidiar con el rendimiento de Ruby en la aplicación web es la misma que con cualquier otro lenguaje de programación:

ARQUITECTURA

Esto es más fácil de hacer en Rails que en la mayoría de los otros marcos web.

A nivel de aplicación , almacenando en caché todo lo que se supone que debe almacenarse en caché y administrando el acceso a la base de datos de forma inteligente (ya que el cuello de botella suele estar en el acceso "DB" para la mayoría de las aplicaciones WEB).

Rails hace que sea muy fácil y natural resolver estos problemas. Hay varias abstracciones para el almacenamiento en caché de datos, páginas y fragmentos , y también hay abstracciones muy agradables para tratar la parte SQL de manera optimizada y reutilizable ( Active Record y AREL ).

Esta es la razón por la cual tantas aplicaciones escritas en lenguajes más rápidos y no tan expresivos (como php) terminan siendo más lentas que las de Ruby. No es tan fácil y elegante abordar el almacenamiento en caché y las consultas con estos idiomas que con Ruby.

A nivel de infraestructura , es razonable pensar en el equilibrio de carga y todas esas cosas de las que no sé mucho. Subcontrataría ese problema contratando alguna plataforma como proveedor de servicios, como Heroku o Engine Yard . De todas formas. Desplegar rieles con equilibrio de carga probablemente no sea muy difícil de hacer.

Ruby es más lento que C ++ en varias tareas fácilmente medibles (por ejemplo, hacer código que depende en gran medida del punto flotante). Esto no es muy sorprendente, pero es suficiente justificación para que algunas personas digan que "Ruby es lento" sin calificación. No cuentan el hecho de que es mucho más fácil y seguro escribir código Ruby que C ++.

La mejor solución es utilizar módulos específicos escritos en otro idioma (por ejemplo, C, C ++, Fortran) en su código Ruby. Esos pueden hacer el trabajo pesado y sus guiones pueden centrarse en problemas de coordinación de nivel superior.

El rendimiento casi siempre se trata de un buen diseño e interacciones optimizadas de la base de datos. Ruby hace lo que la mayoría de los sitios web necesitan bastante rápido, especialmente las versiones más recientes; y la velocidad de desarrollo y la facilidad de mantenimiento proporcionan una gran recompensa en costos y en la satisfacción de los clientes. Considero que JAVA tiene un rendimiento de ejecución lento para algunas tareas, y dada la dificultad de desarrollar en JAVA, muchos desarrolladores crean aplicaciones lentas independientemente de la capacidad de velocidad teórica como se demuestra en los puntos de referencia (los puntos de referencia generalmente están diseñados para mostrar una capacidad específica y estrecha). Cuando necesito un procesamiento intensivo que no se adapta bien a las capacidades de mi base de datos, elijo C u Objective-C u otro lenguaje compilado de alto rendimiento para esas tareas dependiendo de la plataforma. Si necesito crear una aplicación web basada en datos, Yo uso RoR o, a veces, C # ASP.NET dependiendo de otros requisitos; porque todas las plataformas tienen fortalezas y debilidades. La velocidad de ejecución de las cosas que hace su aplicación es importante, pero después de todo, si el rendimiento de ejecución de un aspecto limitado de un lenguaje es lo único que cuenta; entonces todavía podría estar usando el lenguaje Assembler para todo.

La gente dice que Ruby es lento porque comparan los programas de Ruby con los programas escritos en otros idiomas. Tal vez los programas que escribes no necesitan ser más rápidos. Quizás para los programas que escribes Ruby no es el cuello de botella que está ralentizando las cosas.

Ruby 2.1 en comparación con Javascript V8

Ruby 2.1 en comparación con Lua ordinario

Ruby 2.1 en comparación con Python 3

Ruby funciona bien para la productividad del desarrollador. Ruby por naturaleza obliga al desarrollo impulsado por la prueba debido a la falta de tipos. Ruby funciona bien cuando se usa como contenedor de alto nivel para bibliotecas C. Ruby también funciona bien durante los procesos de larga ejecución cuando se compila JIT en código máquina a través de JVM o Rbx VM. Ruby no funciona bien cuando se requiere procesar números en poco tiempo con código de ruby ​​puro.