Е
Но я понял, я-то лично все спекаю, но вдруг придет дебил. Впрочем дебила я уволю нахер :)
Size: a a a
2021 January 08
Е
зависит от того, как ты будешь это использовать. Если сделать guard - не надо будет проверять перед вызовом "а список ли это"
В принципе, всегда точно известно список надо проверить или одно значение. На стадии написания кода.
M
Suren Kirakosyan
Меня вот только присваивание в acc как-то бесит.
Можно ещё сделать возврат undefined | value() из low level функции, тогда она будет отвечать только за маппинг ошибки, а в top level уже сделать добавление в аккамулятор, тогда при добавление новых ошибок не нужно будет писать вечное ++ acc
Е
В общем
match_list делаю, а то в первом случае спека получается слишком общая. И список может вернуть и просто значение, ослабляется контрольSK
Можно ещё сделать возврат undefined | value() из low level функции, тогда она будет отвечать только за маппинг ошибки, а в top level уже сделать добавление в аккамулятор, тогда при добавление новых ошибок не нужно будет писать вечное ++ acc
Ну сейчас и так сойдёт.
LL
В теории компилятор может оптимизировать такое. Даже возможно в рантайме
Компилятор это не будет оптимизировать...
Е
Компилятор это не будет оптимизировать...
Может beam умеет оптимизировать, если список состоит из одного элемента?
Е
Впрочем пофиг. Неинтересно.
LL
Может beam умеет оптимизировать, если список состоит из одного элемента?
Нет, не умеет, я проверил
Е
Нет, не умеет, я проверил
Как? Залез в сырцы Beam?
LL
Как? Залез в сырцы Beam?
Я давным давно проверял оптимизации конкатенации списков
Я просто написал код, скомпилировал его и посмотрел ассемблер, там было создание списка, а потом конкатенация
Я просто написал код, скомпилировал его и посмотрел ассемблер, там было создание списка, а потом конкатенация
Е
Я давным давно проверял оптимизации конкатенации списков
Я просто написал код, скомпилировал его и посмотрел ассемблер, там было создание списка, а потом конкатенация
Я просто написал код, скомпилировал его и посмотрел ассемблер, там было создание списка, а потом конкатенация
Я имел ввиду другое. Ты же посмотрел байт-код верно? А я говорю об оптимизации внутри bif-функции конкатенации.
LL
Я имел ввиду другое. Ты же посмотрел байт-код верно? А я говорю об оптимизации внутри bif-функции конкатенации.
Я посмотрел байт-код
Какая разница что внутри
Какая разница что внутри
BIF, если всё равно [x] ++ list медленее чем [x | list] хотя бы из-за создания списка [x]Е
Я посмотрел байт-код
Какая разница что внутри
Какая разница что внутри
BIF, если всё равно [x] ++ list медленее чем [x | list] хотя бы из-за создания списка [x]Без оптимизации разница может быть огромной.
Е
Впрочем может и не будет. Я не знаю как там устроен список внутри.
Е
В теории действительно не особая разница, долистал до конца первого списка и прицепил второй.
Е
Скорее всего так и есть. Обычные односвязные списки.
LL
Без оптимизации разница может быть огромной.
Учитывая иммутабельность списков, ассимтотика
В любом случае, это всего лишь догадки и лучше писать
x ++ y это O(len(y)) в любом случае. Компилятор, конечно, мог бы это оптимизировать, но механизм редукций врятли позволитВ любом случае, это всего лишь догадки и лучше писать
[x | y], чем [x] ++ yЕ
Ты прав
Е
Учитывая иммутабельность списков, ассимтотика
В любом случае, это всего лишь догадки и лучше писать
x ++ y это O(len(y)) в любом случае. Компилятор, конечно, мог бы это оптимизировать, но механизм редукций врятли позволитВ любом случае, это всего лишь догадки и лучше писать
[x | y], чем [x] ++ yНу это однозначно.