EG
Если нет, не занимайся предварительной оптимизацией.
Size: a a a
2020 January 27
S
Не пишите изначально медленный код - не надо будет заниматься оптимизацией не по делу
EG
Не пишите изначально медленный код - не надо будет заниматься оптимизацией не по делу
Покажи хоть какие-то подтверждения, что lvalue-функции достаточно медленные, чтобы это было заметно на фоне I/O операций
EG
Если ты пишешь не числодробилку, то, вероятно, твой код IO-bound
Если ты пишешь числодробилку, то почему ты это делаешь на Perl?
Если ты пишешь числодробилку, то почему ты это делаешь на Perl?
R
Да, сейчас дискету отформатирую...
S
А вдруг у меня не i/o bound сервис? Ну и вообще, тогда можно взять Moose, но почему-то этого не сделали?)
VG
Покажи хоть какие-то подтверждения, что lvalue-функции достаточно медленные, чтобы это было заметно на фоне I/O операций
да и про хэши тоже услышал бы
EG
А вдруг у меня не i/o bound сервис? Ну и вообще, тогда можно взять Moose, но почему-то этого не сделали?)
Зачем ты пишешь CPU-bound код на Perl?
R
на фоне IO оно конечно незаметно, но в магия работает не бесплатно и, если есть XS, магию там тоже надо пинать, чтобы работала
EG
Всё-таки хотелось бы какой-то пруф на то, что lvalue subroutines медленные
EG
Для меня это выглядит как просто запись по указателю, не вижу, почему им быть медленными.
R
напиши тест
EG
Бремя доказательства лежит на утверждающем.
VG
и пруф о медленных restricted хэшах тож в студию
S
а как в perl6 @imcono ?
EG
а как в perl6 @imcono ?
В Raku дефолтный флоат не IEEE754, а decimal
EG
В Raku дефолтный флоат не IEEE754, а decimal
s/decimal/rational/
c
Ага
EG
Но
1. Если ты делаешь арифметику сложнее сложить/вычесть, то у тебя всё равно вылезают обычные флоаты
2. Очевидно, это счастье работает медленнее, чем настоящие floating point операции
1. Если ты делаешь арифметику сложнее сложить/вычесть, то у тебя всё равно вылезают обычные флоаты
2. Очевидно, это счастье работает медленнее, чем настоящие floating point операции
c
Та не