Каковы реальные проблемы с Ruby? [закрытый]

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

    use Fcntl ':flock'; # import LOCK_* constants

    # open the file for appending
    open (my $fh, '>>', 'test.dat') or die $!;

    # try to lock the file exclusively, will wait till you get the lock
    flock($fh, LOCK_EX);

    # do something with the file here (print to it in our case)

    # actually you should not unlock the file
    # close the file will unlock it
    close($fh) or warn "Could not close file $!";

Выезд полное документация скопления и учебное руководство по Захвату файла на PerlMonks даже при том, что это также использует старый стиль использования дескриптора файла.

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

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

12
задан Dan Rigby 3 May 2012 в 19:01
поделиться

5 ответов

Есть статья под названием Уроки, извлеченные из больших вычислений с помощью Ruby , ее стоит прочитать.

12
ответ дан 2 December 2019 в 20:18
поделиться

Скорость Ruby на самом деле не является его основным вопрос. Самая большая проблема в том, что он однопоточный. Предложение Макса А. хорошее. JRuby допускает параллелизм.

1
ответ дан 2 December 2019 в 20:18
поделиться

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

0
ответ дан 2 December 2019 в 20:18
поделиться

Руби не быстр. У него есть и другие качества, но если ваш процессор является узким местом (что во многих веб-приложениях на самом деле не так), то Ruby не подходит. Текущий «стандартный» Ruby даже не компилируется в байт-код (как, например, Python), а вместо этого интерпретирует AST, что, вероятно, приводит к замедлению в 20–100 раз. Однако это, вероятно, скоро изменится (или, по крайней мере, станет лучше) с Ruby 1.9. И JRuby, который, как вы наверняка знаете, основан на JVM.

2
ответ дан 2 December 2019 в 20:18
поделиться

Если производительность Ruby оставляет желать лучшего в вашем конкретном случае, я рекомендую вам взглянуть на JRuby . Он позволяет компилировать ванильный код Ruby в байт-код JVM в стиле JIT или AOT и дает доступ к совершенству параллелизма Java и отличным серверам приложений.

1
ответ дан 2 December 2019 в 20:18
поделиться
Другие вопросы по тегам:

Похожие вопросы: