Почему люди говорят, что Ruby работает медленно? [закрыто]


184

Мне нравится Ruby on Rails, и я использую его для всех своих проектов веб-разработки. Несколько лет назад было много разговоров о том, что Rails - это боров памяти, и о том, как он не очень хорошо масштабируется, но эти предложения были уложены Греггом Поллаком здесь .

В последнее время я слышал, как люди говорили, что сам Ruby работает медленно.

  • Почему Ruby считается медленным?

Я не считаю Ruby медленным, но опять же, я просто использую его для создания простых приложений CRUD и блогов компании. Какие проекты мне нужно было бы сделать, прежде чем Ruby станет медленным? Или эта медлительность влияет на все языки программирования?

  • Какие у вас есть возможности программиста на Ruby, если вы хотите справиться с этой «медлительностью»?

  • Какая версия Ruby лучше всего подойдет для такого приложения, как Stack Overflow, где скорость критична, а трафик интенсивен?

Вопросы субъективны, и я понимаю, что архитектурная настройка (EC2 по сравнению с автономными серверами и т. Д.) Имеет большое значение, но я хотел бы услышать, что люди думают о медленной Ruby.

Наконец, я не могу найти много новостей о Ruby 2.0 - я так понимаю, что до этого у нас еще несколько лет?




кроме хороших ответов, ни один из них действительно не отвечает ПОЧЕМУ. лучшее понимание в связанном вопросе, упомянутом Накилоном
Андре Фигейредо

Ответы:


184

Почему Ruby считается медленным?

Потому что, если вы запускаете типичные тесты между Ruby и другими языками, Ruby проигрывает.

Я не считаю Ruby медленным, но опять же, я просто использую его для создания простых приложений CRUD и блогов компании. Какие проекты мне нужно было бы сделать, прежде чем Ruby станет медленным? Или эта медлительность влияет на все языки программирования?

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

Помните, что большая часть обработки ваших веб-приложений на самом деле выполняется программным обеспечением, разработанным на C. Например, Apache, Thin, Nginx, SQLite, MySQL, PostgreSQL, многие библиотеки синтаксического анализа, RMagick, TCP / IP и т. Д. - это программы на C, используемые Ruby. , Ruby обеспечивает клей и бизнес-логику.

Какие у вас есть возможности программиста на Ruby, если вы хотите справиться с этой «медлительностью»?

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

Какая версия Ruby лучше всего подойдет для такого приложения, как Stack Overflow, где скорость критична, а трафик интенсивен?

Другие люди ответили на это - JRuby, IronRuby, REE заставят Ruby-часть вашего приложения работать быстрее на платформах, которые могут позволить себе виртуальные машины. А поскольку медлительность часто вызывает не Ruby, а архитектура вашего компьютера и архитектура приложений, вы можете выполнять такие вещи, как репликация базы данных, несколько серверов приложений, балансировка нагрузки с помощью обратных прокси-серверов, HTTP-кэширование, memcache, Ajax, клиентское кэширование и т. Д. Ничто из этого не относится к Ruby.

Наконец, я не могу найти много новостей о Ruby 2.0 - я так понимаю, что до этого у нас еще несколько лет?

Большинство людей ждут Ruby 1.9.1. Я сам жду Rails 3.1 на Ruby 1.9.1 на JRuby.

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


3
после долгих размышлений я решил, что это лучший ответ. Спасибо, мне нравится аналогия с приложением обработки сигналов. Теперь легче понять, о чем говорят люди после всех этих полезных ответов.
stephenmurdoch

1
Да, вы были на пару лет от ruby ​​2, Ruby 2.0.0 выпущен 24 февраля 2013 г.
Морган

3
Мой опыт использования Ruby 2.1 заключается в том, что он примерно на 25% быстрее, чем то же приложение, работающее в Ruby 2.0
Мэтт Коннолли,

14
Языки не медленные и не быстрые, их реализации, интерпретаторы и компиляторы
:)

122

Прежде всего, медленнее, чем ? C? Python? Давайте возьмем некоторые цифры в игре «Тесты компьютерного языка» :

Почему Ruby считается медленным?

Зависит от того, кого вы спрашиваете. Вы могли бы сказать, что:

  • Ruby - это интерпретируемый язык, и интерпретируемые языки будут работать медленнее, чем скомпилированные.
  • Ruby использует сборку мусора (хотя C #, который также использует сборку мусора, выходит на два порядка выше, чем Ruby, Python, PHP и т. Д. В более алгоритмических, менее ресурсоемких тестах выше)
  • Вызовы методов Ruby медленны (хотя из-за утки, возможно, они быстрее, чем в строго типизированных интерпретируемых языках)
  • Ruby (за исключением JRuby) не поддерживает настоящую многопоточность
  • и т.п.

Но, опять же, медленно по отношению к чему? Ruby 1.9 примерно так же быстр, как Python и PHP (с коэффициентом производительности в 3 раза) по сравнению с C (который может быть в 300 раз быстрее), поэтому приведенное выше (за исключением соображений о многопоточности, должно ли ваше приложение сильно зависеть от этого аспекта) ) в значительной степени академические.

Какие у вас есть возможности программиста на Ruby, если вы хотите справиться с этой «медлительностью»?

Пишите для масштабируемости и добавляйте больше оборудования (например, памяти)

Какая версия Ruby лучше всего подойдет для такого приложения, как Stack Overflow, где скорость критична, а трафик интенсивен?

Ну, REE (в сочетании с пассажиром ) будет очень хорошим кандидатом.


1
Сборка мусора сама по себе не обязательно медленная, но сборка мусора в МРТ есть. Если вам нужен более быстрый Ruby, вы также можете посмотреть на JRuby и REE.
Андреас

1
@igouy, правда, середина 2008 года могла быть экстремальной. Я обновил ссылки, но через несколько месяцев они устаревают. :) В любом случае, аппаратное обеспечение и некоторые уровни исправлений могли отличаться, и было добавлено несколько дополнительных тестов, но общая картина не изменилась.
Влад

11
>> в пределах того же порядка величины << Это в пределах того же порядка величины, если вы живете до 7 или до 69. Является ли эта разница незначительной?
igouy

10
@igouy, я не знаю о вас, но я не программа для измерения моей продолжительности жизни с точки зрения скорости выполнения. Например, где меня волнует скорость выполнения, это время рендеринга ответа HTTP. Я знаю, что не замечу разницы между временем рендеринга 7 мс и 69 мс (особенно, когда скорость превышает 130 мс). Я действительно знаю, что я заметил бы разницу между 7 мс и 700 мс, и Я ОБЯЗАТЕЛЬНО заметю разницу между 7 мс и 7 с - но нет, не между 7 мс и 69 мс.
Влад

3
@vladr, а как насчет 70 мс или 700 мс? Вы можете заметить эту разницу?
Пол Дрэйпер

60

Вот что сказал создатель Rails Дэвид Хайнемайер Ханссон :

Rails [Ruby] предназначен для подавляющего большинства веб-приложений. У нас есть сайты, которые делают миллионы динамических просмотров страниц в день. Если вы в конечном итоге окажетесь на главной странице Yahoo или Amazon, маловероятно, что готовая платформа на ЛЮБОМ языке будет вам полезна. Вам, вероятно, придется свернуть свой собственный. Но, конечно же, я бы тоже хотел бесплатные циклы процессора. Меня просто больше волнуют бесплатные циклы разработки, и я готов обменять первое на второе.

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

Ruby 1.9 - это значительное улучшение по сравнению с 1.8. Самыми большими проблемами с Ruby 1.8 является его интерпретируемая природа (без байт-кода, без компиляции), а вызовы методов, одна из самых распространенных операций в Ruby, особенно медленны.

Это не помогает, что почти все это поиск методов в Ruby - добавление двух чисел, индексация массива. Там, где другие языки выставляют хаки ( __add__метод Python , Perl overload.pm), Ruby делает чистый OO во всех случаях, и это может снизить производительность, если компилятор / интерпретатор недостаточно умен.

Если бы я писал популярное веб-приложение на Ruby, я бы сосредоточился на кешировании. Кэширование страницы сокращает время обработки этой страницы до нуля независимо от того, какой язык вы используете. Для веб-приложений издержки базы данных и другие операции ввода-вывода начинают иметь гораздо большее значение, чем скорость языка, поэтому я бы сосредоточился на их оптимизации.


7
«В конце концов, мало кто пишет веб-приложения на C.» - Конечно нет, но многие сайты, критичные к производительности, перешли, например, в Scala.
Дарио

6
Я не согласен с тем, что «выбрасывать больше оборудования» дешевле. Трудно убедить клиентов, что они должны платить больше денег за хостинг каждые X месяцев, потому что их платформа была разработана для разработчиков.
Кевин

9
@ Keven: конечно, затраты на разработку будут снижены? Иначе какой смысл использовать Ruby?
rjh

4
@Kevin Это утверждение немного широкое. Если вам потребуется настраивать новый сервер для каждых 10% увеличения трафика или около того с примерно 100 посещениями в день, клиент, безусловно, будет иметь право жаловаться. Реально, однако, для начала вам нужно иметь гораздо больший трафик и увеличить его на порядок, прежде чем старое оборудование больше не сможет справиться. В этот момент тема переходит на территорию «хорошая проблема иметь», и вряд ли кто-то будет жаловаться на обновление оборудования. Кроме того, ни один «клиент» не запускает сайт с таким высоким трафиком, не зная об этом.
deceze

5
@Kevin - давайте это перевернем. «Трудно убедить клиентов, что они должны ждать 3 месяца для новой функции, потому что их платформа была разработана с учетом компьютеров». Если эта новая функция резко увеличит доход, она заплатит за дополнительное оборудование. Кроме того, выбор быстрого языка с самого начала является для многих приложений преждевременной оптимизацией. Скорее всего, ваше узкое место будет где-то еще: чтение базы данных, задержка в сети и т. Д.
Натан Лонг,

34

Написание кода идет медленно. Чтение кода идет медленно. Поиск и исправление ошибок происходит медленно. Добавление функций и улучшений происходит медленно. Все, что улучшается по сравнению с предыдущим, является победой. Очень редко возникает проблема с исполнением.


30
@GregS: производительность выполнения всегда является проблемой, если она влияет на удобство использования. Да, сканирование XML-файла на наличие строки за одну или три секунды не имеет значения с точки зрения чистых чисел, но разница в пару секунд может существенно повлиять на удобство использования, когда вы говорите о приложении, ориентированном на пользователя.
Брайан Окли

5
@Ajax: нет, держу пари, это ваша победившая личность.
Президент Джеймс К. Полк

15
На данный момент мой рекорд - экономия 30 000 долларов в год за один день работы. Их инженеры решили, что алгоритм облачных вычислений более удобен для подсчета количества задач, выполненных на каждой итерации, что приводит к n! запросы на работу с 20 000+ единиц работы. Изменяя это, чтобы проверить, был ли оставлен 1 рабочий элемент, вы отбросили его до n запросов и сократили счет с 130 до 20 долларов в день. Ленивые кодеры зарабатывают мне деньги. Пожалуйста, поощряйте больше ленивых кодеров.
Аякс

10
Забавно, что вы только что прокомментировали ... Я перешел к другой компании, где нам только что пришлось привлечь пятнадцать разработчиков функций и производительности, поскольку крупный американский банк отказывается подписывать многомиллионный контракт, пока система не будет может справиться с их нагрузкой. Им нравятся функции, которые у нас есть, но не скорость, с которой они работают. Если вы достаточно долго игнорируете производительность, не имеет значения, какие функции у вас есть, потому что они будут необычайно медленными .
Аякс

4
Производительность исполнения - это всегда вопрос, насколько важна проблема, о которой мы говорим. Сколько интерпретированного кода вы можете запустить на мобильном телефоне, прежде чем пользователи перестанут покупать ваше приложение, потому что оно разряжает батареи? Как долго пользователь будет ждать загрузки вашей страницы, прежде чем закрыть объявление, лишающее вас дохода от рекламы? Ответьте на эти вопросы и узнайте, насколько важна эффективность исполнения.
Sqeaky

15

Ответ прост: люди говорят, что рубин медленный, потому что он это медленно на основе измеренных сравнений с другими языками. Имейте в виду, что «медленный» относительный. Часто ruby ​​и другие «медленные» языки достаточно быстрые.


да, это то, о чем я думал, я имею в виду, люди говорят, что это медленно, но это все равно чертовски быстро для моих требований ...
stephenmurdoch

11
>> это все еще чертовски быстро для моих требований << Это достаточно быстро для всего, что не должно быть быстрым :-)
igouy

Я частично склонен к этому, возможно, Кокс, это устаревший комментарий. Теперь у нас есть ruby ​​2.3, и из опыта работы с ruby ​​2.2 я обнаружил, что стек рельсов тяжелый. если вам нужен более быстрый каркас, попробуйте pidrano, основанный на sinatra, и они постарались сделать его как можно ближе к команде рельсов, но намного легче. но они еще не достигли версии 1.0, но это еще не все, но, как показал мой тест, все прошло хорошо и быстро. Я работаю с активной записью 5 и звездочками пидрано, позаимствованными у рельсов. При одновременном соединении 200 я получаю ответ 1,5 с без запроса базы данных с активами звездочек
Джеймс Тан

5

Джоэл о программном обеспечении - Ruby Performance Revisited довольно хорошо это объясняет. Может быть устаревшим, хотя ...

Я бы порекомендовал просто придерживаться этого, поскольку вы привыкли к Ruby on Rails,
если вы когда-нибудь столкнетесь с проблемой производительности, вы можете пересмотреть использование другого языка и фреймворка.

В этом случае я бы действительно предложил C # с ASP.NET MVC 2 , очень хорошо работает для приложений CRUD.


Спасибо за ссылку, мне всегда нравится читать рассказ Джоэла. Интересное замечание, которое он делает по поводу «лозунга с наклейками на бампере»
DHH

Цитата: « Это не относится ко всем, но когда люди говорят, что у них проблемы с производительностью в Ruby или что им просто нужно иметь возможность выполнять код быстрее, чем его может запустить ядро ​​языка Ruby, это не помогает Ruby рекомендует петь гимны о циклах разработки и циклах процессора. "Хорошо сказано.
Marc.2377

3

Я бы сказал, что Ruby работает медленно, потому что на то, чтобы сделать переводчика быстрее, не было потрачено много времени. То же относится и к Python. Smalltalk так же динамичен, как Ruby или Python, но работает на порядок лучше, см. Http://benchmarksgame.alioth.debian.org . Поскольку Smalltalk был более или менее заменен Java и C # (то есть, по крайней мере, 10 лет назад), для него не было проделано никакой работы по оптимизации производительности, и Smalltalk по-прежнему намного быстрее, чем Ruby и Python. У людей в Xerox Parc и OTI / IBM были деньги, чтобы платить людям, которые работают над тем, чтобы сделать Smalltalk быстрее. Я не понимаю, почему Google не тратит деньги на то, чтобы сделать Python быстрее, потому что это большой магазин Python. Вместо этого они тратят деньги на развитие таких языков, как Go ...


Я думаю, что это потому, что Python уже имеет свое место и активно используется в настоящее время. Если вам нужна высокая производительность, есть много библиотек, которые вы можете использовать или переплетать, и другие вещи, которые вы можете использовать.
Зельфир Кальцталь

Из того, что я прочитал, некоторые усилия уже дали хорошие результаты в Ruby 2.5.
Marc.2377

2

Прежде всего, вас волнует, что другие говорят о языке, который вам нравится? Когда он делает работу, которую должен сделать, ты в порядке.

ОО не самый быстрый способ выполнения кода, но он помогает в создании кода. Умный код всегда быстрее, чем тупой код и бесполезные циклы. Я администратор баз данных и вижу множество этих бесполезных циклов, отбрасываю их, использую лучший код и запросы, и приложение работает быстрее, намного быстрее. Вас волнует последняя микросекунда? Возможно, языки оптимизированы для скорости, другие просто выполняют свою работу и могут поддерживаться многими разными программистами.

Это всего лишь выбор.


2

Очевидно, говоря о скорости, Руби проигрывает. Несмотря на то, что тесты показывают, что Ruby не намного медленнее, чем PHP. Но взамен вы получаете простой в обслуживании DRY-код, лучший из всех фреймворков на разных языках.

Для небольшого проекта вы не почувствуете никакой медлительности (я имею в виду до тех пор, как пользователи <50K), учитывая, что в коде не используются сложные вычисления, только основной материал.

Для более крупного проекта оплата ресурсов окупается и дешевле, чем заработная плата разработчиков. Кроме того, написание кода на RoR оказывается намного быстрее, чем на любом другом.

В 2014 году величина разницы в скорости, о которой вы говорите, для большинства веб-сайтов незначительна.


2

Способ работы с Ruby в веб-приложении такой же, как и в любом другом языке программирования:

АРХИТЕКТУРА

Это легче сделать в Rails, чем в большинстве других веб-фреймворков.

На уровне приложения - кэширование всего, что предполагается кэшировать, и интеллектуальное управление доступом к БД (поскольку узкое место обычно заключается в доступе «БД» для большинства веб-приложений).

Rails позволяет очень легко и естественно решить эти проблемы. Есть несколько абстракций для кэширования данных, страниц и фрагментов , а также есть очень хорошие абстракции для работы с частью SQL оптимизированным и многократно используемым способом ( Active Record и AREL ).

Это причина, почему так много приложений, написанных на более быстрых и не очень выразительных языках (таких как php), в конечном итоге работают медленнее, чем аналоги Ruby. С этими языками не так просто и легко справиться с кэшированием и запросами, как с Ruby.

На уровне инфраструктуры разумно подумать о балансировке нагрузки и обо всем этом, о чем мне не так много известно. Я бы передал эту проблему на аутсорсинг, наняв платформу в качестве поставщика услуг, например Heroku или Engine Yard . Тем не мение. Развертывание рельсов с балансировкой нагрузки, вероятно, не очень сложно сделать.


1

Ruby медленнее, чем C ++, в ряде легко измеримых задач (например, при выполнении кода, который сильно зависит от плавающей запятой). Это не очень удивительно, но есть достаточное оправдание для некоторых людей, чтобы сказать, что «Рубин медленен» без квалификации. Они не считают, что писать код на Ruby намного проще и безопаснее, чем на С ++.

Лучшее решение - использовать целевые модули, написанные на другом языке (например, C, C ++, Fortran) в вашем коде Ruby. Они могут сделать тяжелую работу, и ваши сценарии могут сосредоточиться на вопросах координации более высокого уровня.


Сравнения часто проводятся с использованием Java, C #, Python, возможно, Perl, а не C ++.
rjh

5
Конечно. Но я могу заверить вас (как разработчика Tcl), что люди всегда будут несправедливо сравнивать вас с другими языками. Исправление состоит в том, чтобы использовать эти другие языки для компонентов, которые вы соединяете вместе; делать все это на одном языке немного похоже на использование одного инструмента для всех задач. Если у вас есть только молоток, все выглядит как большой палец.
Donal Fellows

хорошая идея об использовании модулей иностранного языка, когда они необходимы
stephenmurdoch

>> сказать, что «Ruby is Slow» без оговорок << Пару лет назад они могли бы показывать программы на Ruby, которые были медленнее, чем программы Tcl :-)
igouy

1
Вы знаете, что они говорят о лжи, проклятой лжи и тестах. ;-)
Donal Fellows

0

Производительность почти всегда зависит от хорошего дизайна и оптимизированного взаимодействия с базой данных. Ruby делает то, что нужно большинству веб-сайтов, довольно быстро, особенно в последних версиях; а скорость разработки и простота обслуживания обеспечивают высокую окупаемость затрат и удовлетворение клиентов. Я считаю, что JAVA имеет низкую производительность выполнения для некоторых задач, и, учитывая сложность разработки в JAVA, многие разработчики создают медленные приложения независимо от теоретической возможности скорости, как продемонстрировано в тестах производительности (тесты, как правило, изобретены, чтобы показать специфическую и узкую возможность). Когда мне нужна интенсивная обработка, которая не очень подходит для возможностей моей базы данных, я выбираю C или Objective-C или другой действительно высокопроизводительный скомпилированный язык для этих задач в зависимости от платформы. Если мне нужно создать веб-приложение на основе данных, Я использую RoR или иногда C # ASP.NET в зависимости от других требований; потому что все платформы имеют свои сильные и слабые стороны. Скорость выполнения того, что делает ваше приложение, важна, но в конце концов, если важна производительность выполнения одного узкого аспекта языка; тогда я все еще мог бы использовать язык Ассемблера для всего.


0

Люди говорят, что Ruby работает медленно, потому что они сравнивают программы на Ruby с программами, написанными на других языках. Может быть, программы, которые вы пишете, не должны быть быстрее. Возможно, для программ, которые вы пишете, Ruby не является узким местом, которое замедляет процесс.

Ruby 2.1 по сравнению с Javascript V8

Ruby 2.1 по сравнению с обычным Lua

Ruby 2.1 по сравнению с Python 3


-5

Ruby хорошо работает для производительности разработчиков. Ruby по своей природе заставляет тестировать управляемую разработку из-за отсутствия типов. Ruby хорошо работает, когда используется в качестве оболочки высокого уровня для библиотек C. Ruby также хорошо работает во время длительных процессов, когда JIT-компилируется в машинный код через JVM или Rbx VM. Ruby не очень хорошо работает, когда требуется за короткий промежуток времени обработать числа чистым рубиновым кодом.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.