Ruby Performance

Question

Tengo muchas ganas de desarrollar mi primera aplicación Ruby, ya que mi empresa finalmente ha bendecido su uso internamente.

En todo lo que he leído sobre Ruby hasta v1.8, nunca hay nada positivo sobre el rendimiento, pero no he encontrado nada sobre la versión 1.9. Las últimas cifras que vi alrededor de 1.8 fueron drásticamente más lentas que casi todo, así que espero que esto se haya tratado en 1.9.

¿Ha mejorado drásticamente el rendimiento? ¿Hay algunas cosas concretas que se pueden hacer con las aplicaciones de Ruby (o cosas que se deben evitar) para mantener el rendimiento al mejor nivel posible?

Answer 1

De hecho, he oído cosas realmente buenas sobre la implementación de JVM, JRuby. Completamente anecdótico, pero quizás valga la pena investigarlo.

Ver también http://en.wikipedia.org/wiki/JRuby#Performance

Answer 2

Hay algunos puntos de referencia de 1,8 frente a 1,9 en http://www.rubychan.de/share/yarv_speedups.html. En general, parece que 1.9 es mucho más rápido en la mayoría de los casos.

Answer 3

Matz ruby ​​1.8.6 es mucho más lento cuando se trata de rendimiento y 1.9 y JRuby hace mucho por acelerarlo. Pero el rendimiento no es tal que le impida hacer lo que quiera en una aplicación web. Hay muchos sitios grandes de Ruby on Rails que funcionan bien con el lenguaje de "interpretación más lenta". Cuando se amplían las aplicaciones web, existen muchos más problemas de rendimiento que la velocidad del idioma en el que se escribe.

Answer 4

Si la escalabilidad y el rendimiento son realmente importantes para usted, también puede consultar Ruby Enterprise Edition. Es una implementación personalizada del intérprete de Ruby que se supone que es mucho mejor acerca de la asignación de memoria y la recolección de basura. No he visto ninguna medida objetiva que la compare directamente con JRuby, pero toda la evidencia anecdótica que he escuchado ha sido muy buena.

Esto es de la misma compañía que creó Passenger (aka mod_rails) que definitivamente debería verificar como una solución de implementación de rieles si decide no ir a la ruta JRuby.

Answer 5

Salida "Escribir eficiente Ruby Code" de Addison Wesley Professional:

http://safari.oreilly.com/9780321540034

He encontrado algunas ideas muy útiles e interesantes en este breve trabajo. Y si te registras para la versión de prueba gratuita de 10 días, puedes leerlo gratis. (Es 50 páginas y el ensayo se obtiene (AFAIR) 100 páginas vistas.)

https://ssl.safaribooksonline.com/promo

Answer 6

no soy un programador de Ruby, pero he estado muy estrechamente involucrado en un despliegue JRuby últimamente y por lo tanto pueden extraer algunas conclusiones . No esperes demasiado del rendimiento de JRuby. En modo interpretado, parece estar en algún lugar dentro del rango de C Ruby. El modo JIT podría ser más rápido, pero solo en teoría. En la práctica, probamos el modo JIT en Glassfish para una aplicación de Rails de un tamaño decente en un servidor de tamaño mediano (doble núcleo, 8 GB de RAM). Y la verdad es que JITting tardó tanto mucho tiempo, que el servidor necesitó 20-30 minutos antes de responder a la primera solicitud. El uso de la memoria era astronómico, los perfiles no funcionaban porque todo el sistema se detenía para detenerse con un generador de perfiles adjunto.

Conclusión: JRuby tiene sus ventajas (multiproceso, plataforma sólida, fácil integración con Java), pero dado que el modo interpretado es el único que nos funcionó en la práctica, se espera que no tenga mejor rendimiento que C Ruby.

Answer 7

Recomendaría la recomendación del uso de Passenger: hace que la implementación y la administración de las aplicaciones de Rails sean triviales