games benchmarksgame benchmark alioth ruby performance

ruby - benchmarksgame - python vs java benchmark



¿Por qué la gente dice que Ruby es lento? (14)

Me gusta Ruby on Rails y lo uso para todos mis proyectos de desarrollo web. Hace unos años se habló mucho sobre que Rails era un cerdo de la memoria y sobre cómo no se escalaba muy bien, pero Gregg Pollack echó mano de estas sugerencias .

Últimamente, sin embargo, he estado escuchando a la gente decir que Ruby en sí misma es lenta.

  • ¿Por qué Ruby se considera lento?

No creo que Ruby sea lento, pero una vez más, solo lo estoy usando para crear aplicaciones simples CRUD y blogs de empresas. ¿Qué tipo de proyectos tendré que hacer antes de que Ruby se vuelva lenta? ¿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 sería más adecuada para una aplicación como Stack Overflow, donde la velocidad es crítica y el tráfico intenso?

Las preguntas son subjetivas, y me doy cuenta de que la configuración arquitectónica (EC2 vs 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 entonces.

¿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 una vez más, solo lo estoy usando para crear aplicaciones simples CRUD y blogs de empresas. ¿Qué tipo de proyectos tendré que hacer antes de que Ruby se vuelva lenta? ¿O es esta lentitud algo que afecta a todos los lenguajes de programación?

Es probable que Ruby no le sirva bien 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 en día) probablemente se ahogaría en una computadora con recursos limitados, como los teléfonos inteligentes.

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

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

Cambia a un lenguaje 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 justifica el uso de un lenguaje más rápido que cuesta mucho más para desarrollarse.

¿Qué versión de Ruby sería más adecuada para una aplicación como , donde la velocidad es crítica y el tráfico intenso?

Otras personas han respondido esto: JRuby, IronRuby, REE hará que la parte de 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 lentitud, sino la arquitectura de su sistema y su arquitectura, puede hacer cosas como replicación de bases de datos, múltiples servidores de aplicaciones, balanceo de carga con proxies inversos, almacenamiento en caché HTTP, Memcache, Ajax, almacenamiento en caché del lado del cliente, etc. . Nada de esto es Ruby.

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

La mayoría de la gente está esperando 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 idiomas, y porque Ruby with Rails permite a los desarrolladores web capacitados desarrollar aplicaciones muy rápidamente.

Antes que nada, ¿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 veo muchos de estos bucles inútiles, soltarlos, utilizar mejor código 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.

Es solo una elección.

Diría que Ruby es lento porque no se ha dedicado mucho esfuerzo para hacer que el intérprete sea más rápido. Lo mismo aplica a Python. Smalltalk es tan dinámico como Ruby o Python, pero tiene un mejor rendimiento en magnitud, ver http://benchmarksgame.alioth.debian.org . Ya que Smalltalk fue más o menos reemplazado por Java y C # (es decir, hace al menos 10 años) no se hizo más trabajo de optimización del rendimiento y Smalltalk sigue siendo mucho más rápido que Ruby y Python. Las personas de Xerox Parc y de OTI / IBM tenían el dinero para pagarle 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 Python más rápido, ya que son una gran tienda de Python. En su lugar, gastan dinero en el desarrollo de lenguajes como Go ...

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 proporcionan una gran recompensa en los costos y en mantener contentos a los clientes. Encuentro 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 se diseñan 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 o Objective-C o algún otro lenguaje compilado de alto rendimiento para esas tareas dependiendo de la plataforma. Si necesito crear una aplicación web basada en datos, 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 la ejecución de un aspecto estrecho de un idioma es lo único que cuenta; entonces aún podría estar usando el lenguaje Assembler para todo.

En primer lugar, ¿ más lento con respecto a qué ? ¿DO? ¿Pitón? Vamos a obtener algunos números en el Juego de puntos de referencia del idioma de la computadora :

¿Por qué Ruby se considera lento?

Depende de a quién le preguntes. Le pueden decir que:

  • Ruby es un lenguaje interpretado y los lenguajes interpretados tenderán a ser más lentos que los compilados
  • Ruby usa la recolección de basura (aunque C #, que también usa la 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, con menor cantidad de memoria e intensidad)
  • Las llamadas al método Ruby son lentas (aunque, debido a la tipificación del pato, son posiblemente más rápidas que en los lenguajes interpretados fuertemente tipados)
  • Ruby (con la excepción de JRuby) no es compatible con true multihilo
  • etc.

Pero, de nuevo, ¿lento con respecto a qué? Ruby 1.9 es tan rápido como Python y PHP (dentro de un factor de rendimiento de 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 consideraciones de enhebrado, su aplicación debe depender 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"?

Escribir para la escalabilidad y lanzar más hardware en él (por ejemplo, memoria)

¿Qué versión de Ruby sería más adecuada para una aplicación como , donde la velocidad es crítica y el tráfico intenso?

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

Escribir código es lento. El código de lectura es lento. Encontrar y corregir errores es lento. Agregar funciones y mejoras es lento. Todo lo que mejore en el anterior es un triunfo. Muy raramente el rendimiento de ejecución es un problema.

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 lo suficientemente rápido. Obtuvimos sitios que realizan millones de visitas a páginas dinámicas por día. Si terminas con la página principal de Yahoo o Amazon, es poco probable que un marco fuera de la plataforma en CUALQUIER idioma te sirva de mucho. Probablemente tendrás que hacer tu propio. Pero claro, me gustaría ciclos de CPU gratis también. Simplemente me preocupo mucho más por los ciclos de desarrollo gratuitos y estoy dispuesto a cambiar el anterior por el último.

es decir, arrojar 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 1.8. Los mayores problemas con Ruby 1.8 son su naturaleza interpretada (sin bytecode, sin compilación) y que 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, agregando dos números, indexando una matriz. Donde otros lenguajes exponen hacks (método __add__ de Python, __add__ de __add__ ) Ruby hace OO puro en todos los casos, y esto puede perjudicar 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 memoria caché de una página reduce el tiempo de procesamiento para esa página a cero, sea cual sea el idioma que esté utilizando. Para 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 concentraría en optimizar eso.

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 Frameworks Web.

En el nivel de aplicación , al almacenar en caché todo lo que se supone que debe almacenarse en caché y al administrar el acceso al DB de una manera 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 muy buenas abstracciones para tratar la parte SQL de forma 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 lentos que las contrapartes de Ruby. No es tan fácil y elegante abordar el almacenamiento en caché y las consultas con estos idiomas de lo que es con Ruby.

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

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, "lento" es relativo. A menudo, el rubí y otros lenguajes "lentos" son bastante rápidos.

Obviamente, hablando de la velocidad que pierde Ruby. Aunque las pruebas comparativas sugieren que Ruby no es mucho más lento que PHP. Pero a cambio, obtiene 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 (me refiero a hasta <50,000 usuarios) dado que no se usan 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 del desarrollador. 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 habla es para la mayoría de los sitios web insignificante.

Ruby es más lento que C ++ en una cantidad de tareas fácilmente medibles (por ejemplo, hacer código que es altamente dependiente 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 de Ruby que C ++.

La mejor solución es usar módulos específicos escritos en otro idioma (p. Ej., C, C ++, Fortran) en su código Ruby. Esos pueden hacer el trabajo pesado y sus guiones pueden enfocarse en problemas de coordinación de nivel más alto.

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

Joel en Software - Ruby Performance Revisited lo explica bastante bien. Puede ser obsoleto ...

Recomendaría seguir con esto, 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 las aplicaciones CRUD.