Добавил две основные главы и одну с сылками. Может однажды я закончу перевод :)
Он конечно не идеальный, потому что тема довольно таки непростая, если кто-то грамотнее найдёт ошибки — пишите.
Добавил две основные главы и одну с сылками. Может однажды я закончу перевод :)
Он конечно не идеальный, потому что тема довольно таки непростая, если кто-то грамотнее найдёт ошибки — пишите.
Проблем с переводом нет, есть проблемы с оригиналом. К сожалению, помимо здравых мыслей автор местами дает совершенно вздорные советы, а иногда просто фантазирует. Пример (цитата по оригиналу):
Это фантазия. Пишем тест и получаем результат:Цитата:
One quoted strings are processed faster by the engine.
Отчетливо видно, что в пределах точности измерений никаких отличий скорости обработки "одинарных" и "двойных" строк нет. Читаем там же далее:Код:Double: 3.888000011444092
Single: 3.9579999446868896
Double: 3.822999954223633
Single: 3.8399999141693115
Double: 3.8470001220703125
Single: 3.825000047683716
Double: 3.822999954223633
Single: 3.7880001068115234
Double: 3.7909998893737793
Single: 3.8519999980926514
Double: 3.815999984741211
Single: 3.8470001220703125
Double: 3.822999954223633
Single: 3.8259999752044678
Double: 3.877000093460083
Single: 3.944000005722046
Double: 3.8610000610351562
Single: 3.883999824523926
Double: 3.811000108718872
Single: 3.857999801635742
Проверка на тесте дает неожиданный результат:Цитата:
Don’t use variable embedding if you have just one value. You can just use value.to_s which will convert value into a string.
Т.е. вариант через #{} работает быстрее, чем ручной вызов to_s и конкатенация.Код:Inline: 10.55400013923645
Concat: 10.940000057220459
Inline: 10.526000022888184
Concat: 10.924999952316284
Inline: 10.430999994277954
Concat: 11.036999940872192
Inline: 10.292999982833862
Concat: 10.919000148773193
Inline: 10.253000020980835
Concat: 10.759000062942505
Inline: 10.325000047683716
Concat: 10.876999855041504
Inline: 10.312999963760376
Concat: 10.963000059127808
Inline: 10.270999908447266
Concat: 10.88699984550476
Inline: 10.283999919891357
Concat: 10.791000127792358
Inline: 10.242000102996826
Concat: 10.792999982833862
Объясняется это тем, что ruby, вопреки заблуждениям автора, не интерпретатор. Перед исполнением кода выполняется весьма изощренная оптимизация. И конструкции вида "Foo#{i}" поддаются оптимизации лучше, чем "Foo"+i.to_s.
Так что читать следует с осторожностью, верить не всему. :)
SCoon, здравые замечания, я сам тестов не проводил, но и в общем-то никто не агитирует слепо верить статье :) А в какой среде тесты проводились?
Хорошо, когда грамотный человек может написанное поставить под сомнение. Я бы даже с интересом ваши комментарии и по остальной информации в статье почитал.
Спасибо, SCoon, за то что поднял тему на главную.
И огромное спасибо Arnon'у за написание ее.
По поводу:
" И конструкции вида "Foo#{i}" поддаются оптимизации лучше, чем "Foo"+i.to_s."
На самом деле 1 операция работает быстрее чем 3.
Сейчас объясню поподробнее: строка Foo#{i} создает объект-строку и помещает ее кучу(надеюсь в Ruby все такие есть понятие "куча").
А давайте проследим что делает строка "Foo"+i.to_s." первым делом она делает объект "Foo" и помещает его в кучу. Затем она делает объект строку - i.to_s(вторая операция) и помещает его в кучу...далее она делает сложение строк, результатом которой есть третий объект "Foo"+i.to_s."(вот она третья операция)....
Итого: мы сделали 3 операции и два лишних объекта в куче...
Не совсем. Где ruby возьмет значение этой строки -- при компиляции оно еще не известно, в нем есть переменная i? Соответственно, при исполнении в некотором буфере будет размещен префикс "Foo", затем для i будет вызван to_s и произведена конкатенация. Но в этом варианте не обязательно будет использована куча. Вполне может быть задействован статический временный буфер.
Т.е. операций все равно будет три, но выполняться они будут чуть иначе. И, как оказалось, чуть быстрее.
Чтобы не засорять тред, запостил еще один комментарий к оригиналу в дневнике.
Очень рад, что у нас поселилось новое светило скриптинга! Надеюсь, наше сотрудничество будет плодотворным и длительным! ))
Ладно, как в Ruby все неоднозначно, по сравнению с Java)))