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

En primer lugar, más lento con respecto a lo? ¿C? Python? Vamos a obtener algunos números en el Juego Computer Language Benchmarks :

• Ruby 1.9 vs Python3 en el mismo orden de magnitud
• Ruby 1.9 vs PHP en el mismo orden de magnitud
• Ruby 1.9 vs. Java 6 server hasta dos órdenes de magnitud más lento!
• Ruby 1.9 vs C (gcc) hasta dos órdenes de de magnitud más lento!
• ...

¿Por qué Ruby se considera lento?

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

• Ruby es un lenguaje interpretado y los lenguajes 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 el más algorítmico, menos puntos de referencia intensivos de asignación de memoria anteriores)
• Ruby las llamadas al método son lentas (aunque, debido a duck typing, son posiblemente más rápidas que en lenguajes interpretados fuertemente tipeados)
• Ruby (con la excepción de JRuby) no soporta verdadero multihilo
• etc.

Pero, por otra parte, 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 300 veces más rápido), por lo que lo anterior (con la excepción de las consideraciones de roscado, si su aplicación depende en gran medida de este aspecto) son en gran medida académicos.

¿Cuáles son tus opciones como programador Ruby si quieres lidiar con esta "lentitud"?

Escribe para escalabilidad y lanza más hardware (por ejemplo, memoria)

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

Bien, 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 aplicaciones web Lo Suficientemente Rápido. Nos tengo sitios haciendo millones de dinámicas páginas vistas por día. Si terminas estar con el frente de Yahoo o Amazon página, es poco probable que un marco off-the-shelve en CUALQUIER el lenguaje te hará mucho bien. Vas a probablemente tenga que rodar la suya. Pero claro, me gustaría ciclos de CPU gratis también. Me solo sucede a preocupa mucho más ciclos de desarrollador libre y estoy dispuesto 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 sobre la 1.8. Los mayores problemas con Ruby 1.8 son su naturaleza interpretada (sin bytecode, sin compilación) y ese método llama, uno de los más las operaciones comunes en Ruby, son particularmente lentas.

No ayuda que casi todo sea una búsqueda de métodos en Ruby - agregando dos números, indexando una matriz. Donde otros lenguajes exponen hacks (método de Python __add__, 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 procesamiento tiempo para esa página a cero, sea cual sea el idioma que esté utilizando. Para las aplicaciones web, la sobrecarga de la base de datos y otras E/S comienza a importar mucho más que la velocidad del lenguaje, por lo que me centraría en optimizarlo.

Escribir código es lento. La lectura del código es lenta. Encontrar y corregir errores es lento. Agregar características y mejoras es lento. Cualquier cosa que mejore sobre el anterior es una victoria. Muy rara vez el rendimiento de la ejecución es un problema.

La respuesta es simple: la gente dice que ruby es lento porque es lento basado en comparaciones medidas con otros idiomas. Sin embargo, tenga en cuenta que "lento" es relativo. A menudo, ruby y otros lenguajes "lentos" son lo suficientemente rápidos.

Joel sobre el Software - Ruby Performance Revisited muy bien lo explica. Aunque podría estar anticuado...

Yo recomendaría simplemente seguir con él, ya que estás acostumbrado a Ruby on Rails,
si alguna vez se encuentra con un problema de rendimiento, puede reconsiderar el uso de un lenguaje y marco diferente.

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

Yo diría que Ruby es lento porque no se ha invertido mucho esfuerzo en 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 por magnitud, ver 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 había hecho más trabajo de optimización de rendimiento para él y Smalltalk sigue siendo mucho más rápido que Ruby y Python. La gente de Xerox Parc y en OTI / IBM tenía el dinero para pagar a la gente que trabaja en hacer Smalltalk más rápido. Lo que no entiendo es por qué Google no gasta el dinero para hacer Python más rápido, ya que son una gran tienda de Python. En cambio, gastan dinero en el desarrollo de idiomas 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 DBA y ver un montón de estos bucles inútiles, soltarlos, utilizar mejor código y consultas y la aplicación es más rápido, mucho más rápido. ¿Te importa el último microsegundo? Es posible que tenga idiomas optimizados para velocidad, otros solo 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. A pesar de que las pruebas de benchmark sugieren que Ruby no es mucho más lento que PHP. Pero a cambio, obtendrá código SECO fácil de mantener, el mejor de todos los frameworks en varios idiomas.

Para un proyecto pequeño, no sentirás ninguna lentitud (me refiero a usuarios de

Para un proyecto más grande, pagar por los recursos vale la pena y es más barato que 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 la diferencia de velocidad de la que estás hablando es insignificante para la mayoría de los sitios web.

La forma de lidiar con el rendimiento de Ruby en aplicaciones 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 Frameworks Web.

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

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

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

A nivel de infraestructura es razonable pensar en el equilibrio de carga y todas esas cosas de las que no sé mucho. Yo externalizaría ese problema contratando alguna plataforma como proveedor de servicios, como Heroku o Engine Yard. Por cierto. La implementación de rails con equilibrio de carga probablemente no sea muy difícil de hacer.

Ruby es más lento que C++ en un número de tareas fácilmente medibles (por ejemplo, hacer código que depende en gran medida del punto flotante). Esto no es muy sorprendente, pero 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 usar módulos dirigidos escritos en otro lenguaje (por ejemplo, C, C++, Fortran) en su código Ruby. Esos pueden hacer el trabajo pesado y sus scripts pueden centrarse en problemas de coordinación de nivel superior.

El rendimiento casi siempre se trata de un buen diseño y de interacciones optimizadas con 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 proporciona una gran rentabilidad en costos y en mantener contentos a los clientes. Me parece 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 demostrado en puntos de referencia (los puntos de referencia son generalmente ideados 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 bases de datos, utilizo RoR o a veces C# ASP.NET dependiendo de otros requisitos; porque todas las plataformas tienen fortalezas y debilidades. Ejecución la velocidad de las cosas que hace su aplicación es importante, pero después de todo, si el rendimiento de ejecución de un aspecto estrecho de un lenguaje es todo lo que cuenta; entonces podría seguir usando el lenguaje Ensamblador para todo.

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

Ruby 2.1 comparado con Javascript V8

Ruby 2.1 comparado con Lua ordinario

Ruby 2.1 comparado con Python 3

Ruby funciona bien para la productividad del desarrollador. Ruby por naturaleza fuerza el desarrollo impulsado por pruebas debido a la falta de tipos. Ruby funciona bien cuando se usa como un contenedor de alto nivel para bibliotecas C. Ruby también funciona bien durante procesos largos cuando se compila JIT a 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 ruby puro.