Почему люди говорят, что Ruby медленный?

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

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

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

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

  • Каковы ваши варианты как программиста Ruby, если вы хотите справиться с этой "медлительностью"?

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

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

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

Ответ 1

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

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

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

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

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

Каковы ваши варианты как Ruby программист, если вы хотите иметь дело с эта "медлительность"?

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

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

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

Наконец, я не могу найти много новостей о Ruby 2.0 - я считаю, что мы хорошие лет от этого?

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

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

Ответ 2

Прежде всего, медленнее относительно того, что? C? Python? Пусть получит некоторые числа в Компьютерные игры Benchmarks Game:

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

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

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

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

Каковы ваши варианты в качестве программиста Ruby, если вы хотите справиться с этой "медлительностью"?

Записать для масштабируемости и добавить в него больше аппаратных средств (например, память)

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

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

Ответ 3

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

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

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

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

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

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

Ответ 4

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

Ответ 5

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

Ответ 6

Joel on Software - Revisited Ruby это хорошо объясняет. Может быть устаревшим, хотя...

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

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

Ответ 7

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

Ответ 8

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

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

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

Ответ 9

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

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

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

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

Ответ 10

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

АРХИТЕКТУРА

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

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

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

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

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

Ответ 11

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

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

Ответ 12

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

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

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

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

Ответ 13

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

Ответ 14

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