какие-то профиты от оптимизации компилятора ?
нет
Хм, тогда странно, что в большинстве случаев, тот код, что доводилось мне смотреть, использовал не мутабельнве колеекции и просто каждый раз копировал всё содержимое ради одного изменения. Ну в таком вот кейсе будет какая-то оптимизация? Или все будет реально выделяться по новой? Я про toMutableList
Потому что это более безопасный стиль. Это не всегда оправдано, но часто
Тут такое дело, что в принципе оптимизации чейнов типа map.filter.reduce вполне возможны. И та же LLVM (Kotlin/Native) их умеет делать. Но вот для JVM такие оптимизации дороговаты, поэтому не ввели. Вот только причина избегать этого копирования одна - бутылочное горлышко реально на этом чейне циклов.
Да вообще не в этом дело. Там де-факто тот же ArrayList обычно. Теоретически возможны оптимизации с true-immutable листами, но пока они не настолько востребованы, чтобы с этим заморачиваться
А тут про копирование речь или про циклы в чейнах?
Про циклы поянтно - оптимизировать можно, но смысла нет. А вот копии по спеке должны быть
Да вот там, где это реально проблема можно спокойно написать ручками аллокацию и сделать все, что нужно
Обсуждают сегодня