Ruby Performance - PullRequest
       31

Ruby Performance

7 голосов
/ 25 августа 2008

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

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

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

Ответы [ 7 ]

8 голосов
/ 25 августа 2008

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

4 голосов
/ 25 августа 2008

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

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

2 голосов
/ 25 августа 2008

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

1 голос
/ 25 августа 2008

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

См. Также http://en.wikipedia.org/wiki/JRuby#Performance

0 голосов
/ 06 сентября 2008

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

0 голосов
/ 06 сентября 2008

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

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

0 голосов
/ 31 августа 2008

Проверьте "Написание эффективного кода Ruby" от Addison Wesley Professional:

http://safari.oreilly.com/9780321540034

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

https://ssl.safaribooksonline.com/promo

...