Причины не компилировать - PullRequest
0 голосов
/ 20 января 2010

Получив проект Ruby, я скептически отнесся к решению использовать Ruby из-за производительности.

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

С контрольными показателями, такими как:

fib (30) Рубин: 1.67s

fib (30) JRuby interp (клиентская виртуальная машина): 3,93 с

fib (30) JRuby interp (виртуальная машина сервера): от 2,28 до 2,08 с

fib (30) JRuby скомпилировано (клиентская виртуальная машина): от 1,89 до 1,79 с

fib (30) JRuby скомпилировано (серверная виртуальная машина): от 1,66 до 0,86

Я сейчас очень взволнован нашим выбором JRuby здесь. Есть ли какие-либо недостатки или причины, по которым вы бы не скомпилировали рабочий выпуск?

Ответы [ 2 ]

1 голос
/ 20 января 2010

Распределение и установка облегчили бы мне это решение: как системный администратор я бы предпочел распространять только файл .JAR, который может работать на многих JRE, чем распределять работающий экземпляр JRuby (который отличается для разных Операционные системы, например) и мой исходный код. Кроме того, вы уже продемонстрировали, что AOT-скомпилированный код работает быстрее, чем интерпретируемый / JIT, поэтому все больше причин распространять скомпилированную версию.

0 голосов
/ 20 января 2010

Ruby очень быстро развивается (если вы знакомы с его стилем).

Не так быстро бегать, но обычно это не большой минус. Это достаточно быстро для большинства рабочих нагрузок, даже для крупных веб-сайтов.

Решение не должно основываться на скорости выполнения - если у вас нет статистики, чтобы сказать, что люди, как ожидается, будут недовольны производительностью - скорее, простота развертывания.

Если развертывание приложений Ruby было достигнуто вашими предшественниками, то оставьте его Ruby.

Если развертывание в JVM проще, воспользуйтесь этим.

...