Ruby Performance

Question

Я очень заинтересован в разработке своего первого приложения Ruby, так как моя компания наконец-то благословила его использование внутри.

Во всем, что я читал о Ruby до v1.8, никогда ничего хорошего не говорится о производительности, но я ничего не нашел о версии 1.9. Последние цифры, которые я видел около 1,8, были значительно медленнее, чем почти все, поэтому я надеюсь, что это было рассмотрено в 1.9.

Имеет ли производительность значительно улучшен? Есть ли какие-то конкретные вещи, которые можно сделать с помощью приложений Ruby (или вещей, которых следует избегать), чтобы поддерживать производительность на максимально возможном уровне?

Answer 1

Я действительно слышал о действительно хороших вещах, связанных с реализацией JVM, JRuby. Совершенно анекдотично, но, возможно, стоит посмотреть.

Смотрите также http://en.wikipedia.org/wiki/JRuby#Performance

Answer 2

Есть некоторые эталоны 1,8 против 1,9 в http://www.rubychan.de/share/yarv_speedups.html. В целом, похоже, что 1.9 в большинстве случаев намного быстрее.

Answer 3

Matz ruby ​​1.8.6 намного медленнее, когда дело доходит до производительности, и 1.9 и JRuby делают многое, чтобы ускорить его. Но производительность не такова, что она помешает вам делать что-либо в веб-приложении. Есть много крупных сайтов Ruby on Rails, которые отлично сочетаются с языком с более медленным пониманием. Когда вы добираетесь до масштабирования веб-приложений, возникает гораздо более актуальная проблема с производительностью, чем скорость языка, на котором вы его записываете.

Answer 4

Если масштабируемость и производительность действительно важны для вас, вы также можете проверить Ruby Enterprise Edition. Это обычная реализация интерпретатора Ruby, который должен быть намного лучше в отношении распределения памяти и сбора мусора. Я не видел каких-либо объективных показателей, сравнивающих их непосредственно с JRuby, но все те анекдотические данные, которые я слышал, были очень хорошими.

Это из той же компании, которая создала Passenger (aka mod_rails), которую вы обязательно должны проверить в качестве решения для развертывания рельсов, если вы решите не идти по маршруту JRuby.

Answer 5

Заканчивать "Написание Эффективное Ruby, код" из Addison Wesley Professional:

http://safari.oreilly.com/9780321540034

Я нашел некоторые очень полезные и интересные идеи в этой короткой работе. И если вы зарегистрируетесь на бесплатную 10-дневную пробную версию, вы можете бесплатно ее прочитать. (Это 50 страниц и суд получает вас (AFAIR) 100 просмотров страниц.)

https://ssl.safaribooksonline.com/promo

Answer 6

Я не программист рубин, но я был довольно плотно вовлечен в развертывании JRuby в последнее время и, таким образом, сделать некоторые выводы , Не ожидайте многого от производительности JRuby. В интерпретируемом режиме он, кажется, находится где-то в диапазоне C Ruby. Режим JIT может быть Быстрее, но только в теории. На практике мы попробовали JIT-режим на Glassfish для приложения Rails с приличным размером на сервере среднего размера (двухъядерный, 8 ГБ оперативной памяти). И правда в том, что JITting занял так freakingly много времени, что серверу понадобилось 20-30 минут, прежде чем он ответил на первый запрос. Использование памяти было астрономическим, профилирование не сработало, потому что вся система остановилась при подключенном профилировщике.

Итог: JRuby имеет свои достоинства (многопоточность, прочная платформа, простая интеграция с Java), но учитывая, что интерпретируемый режим является единственным режимом, который сработал для нас на практике, можно ожидать, что он не будет лучше с точки зрения производительности, чем C Ruby.

Answer 7

Я бы порекомендовал использование пассажира - он делает развертывание и управление приложениями Rails тривиальными