Size: a a a

2020 September 07

V

Valery in RubyRush
Kirill Ilyin
Как это нет условия в цикле while, когда вы его написали? x.zero? эта конструкция проигрывает конструкции x == 0 ровно в один символ, иногда это очень важно помнить про это.
В выражении while true true - это не условие, а булево значение.
Вот для сравнения другое выражение:
while i > 10
в котором i > 10 - именно условие.

Я просто говорю, что для англоговорящего человека while true - это что-то странное, а while i > 10 - нормальное английское выражение.
источник

V

Valery in RubyRush
Ещё разница между loop и while в том, что если внутри loop вызвать исключение StopIteration, то произойдёт просто выход из цикла, в если его вызвать в другом месте, например, внутри while, то будет сгенерировано исключение, которое, будучи не обработанным, приведёт к аварийному завершению программы.
источник

WT

William Tombleson in RubyRush
Denis Gavrilin
Почему? while раза в два быстрее loop
источник

RY

Ruslan Yand in RubyRush
while 2 + 2 == 4  )))
источник

RY

Ruslan Yand in RubyRush
while(2.+(2).==(4)) что-то жуткое выходит ))
источник

Э

Эдем in RubyRush
Denis Gavrilin
@installero @ValeryVasilkov Понятно, спасибо, хоть и не согласен на ровном месте идти в ущерб скорости
Да вот х.з. на счёт производительности, кстати. Думаю, что от кода зависит ещё. Например, в while переменные c какими-то огромными массивами если будут, то они останутся в памяти после выхода, а в loop нет

Или если итераций не так много, то выигрыш while true будет просто не заметен

Короче говоря, задрачиваться на скорости нужно только тогда, когда нужно задрачиваться
источник

VV

Vadim Venediktov in RubyRush
Эдем
Да вот х.з. на счёт производительности, кстати. Думаю, что от кода зависит ещё. Например, в while переменные c какими-то огромными массивами если будут, то они останутся в памяти после выхода, а в loop нет

Или если итераций не так много, то выигрыш while true будет просто не заметен

Короче говоря, задрачиваться на скорости нужно только тогда, когда нужно задрачиваться
👍
источник

VV

Vadim Venediktov in RubyRush
Но знать про такое важно, на собесах спросить могут :)
источник

Э

Эдем in RubyRush
Если кому интересно, на эту тему на SO как-то писал:

https://stackoverflow.com/a/54319176
источник

RY

Ruslan Yand in RubyRush
Эдем
Если кому интересно, на эту тему на SO как-то писал:

https://stackoverflow.com/a/54319176
Почитаемс.
источник

M

Michael in RubyRush
Denis Gavrilin
@installero @ValeryVasilkov Понятно, спасибо, хоть и не согласен на ровном месте идти в ущерб скорости
Это неверный в корне подход.

Разница в скорости настолько несущественная обычно, что вы ее даже не сможете измерить.

А недостатки качества кода вам могут вылететь в много человекодней багфиксов.
источник

M

Michael in RubyRush
Это в принципе неверная психология в высокоуровневых языках «экономить на спичках».

Вот когда в реальности столкнётесь с многомиллионными нагрузками и боттлнеками, тогда и надо заниматься оптимизацией.

И вы удивитесь что обычно эти боттлнеки оказываются вовсе не там, где вы ожидали.
источник

M

Michael in RubyRush
А в вебе например тормоза на сетевых вопросах появляются намного раньше деталей кода.

Я кстати за весь опыт не помню ни одной реальной проблемы из-за неудачно выбранного синтаксиса (при условии, что алгоритм и данные выбраны верно) - ни в жаве, ни в руби, ни в js.
источник

mB

mr Bubble in RubyRush
Ага, я использую такой подход и погорел чутка, приложение начало тормозить где-то при 500 заказах в базе, при подходе к 1000 - работать уже было некомфортно, я рассчитывал что до 10к оптимизировать не надо будет, пришлось раньше заморачиваться и вместо рендеринга вьюх отдавать джейсон клиенту, а он уже рендерит
теперь жду когда этот вариант начнет тормозить))))
источник

mB

mr Bubble in RubyRush
еще настроил http2 большая часть страниц грузится менее 1-2 секунд.
источник

E

Eugene in RubyRush
mr Bubble
Ага, я использую такой подход и погорел чутка, приложение начало тормозить где-то при 500 заказах в базе, при подходе к 1000 - работать уже было некомфортно, я рассчитывал что до 10к оптимизировать не надо будет, пришлось раньше заморачиваться и вместо рендеринга вьюх отдавать джейсон клиенту, а он уже рендерит
теперь жду когда этот вариант начнет тормозить))))
"ДЕоптимизировать" тоже не надо
источник

E

Eugene in RubyRush
т.е. если есть некая общепринятая практика, как делаются некие вещи, не надо использовать специально более медленное и корявое решение, якобы следуя принципу "не делать преждевременную оптимизацию"
источник

mB

mr Bubble in RubyRush
Я сделал и запустил приложение для своей конторы для приема заказов, оно отлично работало, я понимал что когда база наполнится оно начнет тормозить, но не знал когда. Знаний и опыта у меня немного, поэтому в процессе пошел на интенсив ХП. Я не специально его таким делал, я просто как умел так и сделал
источник

E

Eugene in RubyRush
mr Bubble
Я сделал и запустил приложение для своей конторы для приема заказов, оно отлично работало, я понимал что когда база наполнится оно начнет тормозить, но не знал когда. Знаний и опыта у меня немного, поэтому в процессе пошел на интенсив ХП. Я не специально его таким делал, я просто как умел так и сделал
Ну вот "1000 заказов в базе" не звучит как повод для применения неких особенных практик оптимизации. Может быть некоторые другие аспекты вашего приложения, которые остались за рамками вашего краткого описания, и в самом деле потребовали "оптимизаций".
источник

mB

mr Bubble in RubyRush
В контроллере было @orders = Order.all а во вьюхе @orders.each do |order|
источник