Сегодня решил посмотреть на некоторые вещи из версии 1.5. Надеялся, что компилятор станет немного умнее в отношении inline(value) class, но посмотрев в декомпилированный код понял, что компилятор по прежнему продолжает делает операцию boxing, хотя упакованое значение уже и так есть. Используя inline(value) class в некоторых случах мы не то чтобы остаемся по затратам на уровне с обычными классами, но даже проигрываем.

А Вы учитываете магию рантайма? Всё же производительность надо проверять только с помощью корректных тестов - тут JMH хорошо подойдёт.

Интересно как runtime оптимизирует функцию A1.box_impl ? Создание не нужных экземпляров объектов никуда же ведь не денется.

Наверное, о таком случае оптимизации просто никто не подумал. Рекомендую завести тикет про это в kotl.in/issue. Будет круто приложить пример реального кода, где встречается передача одного и того же значения value-класса в несколько мест требующих боксинг.

У вас там лист, а в листе будет боксинг даже если там просто Int.

@altavir

У вас там лист, а в листе будет боксинг даже если там просто Int.

Так суть не в листе, а в регулярном boxing/unboxing

В смысле что блоке каждый раз на вызов it анбоксится? Так это уже не к инлайн классам вопрос, а к тому, как компилятор оптимизирует это. Никак не оптимизирует, но это действительно почти наверняка будет оптимизировано в рантайме

сообщение выше. А насчет рантайма соглашусь. В целом не вижу проблем особых.

Может ли котлин ловить этот кейс для примитивов и инлайнов и оптимизировать на стадии генерации байт-кода? Может. Но для этого надо специальный интринсик заводить. Там была значительно более интересная попытка сделать листы примитивов без боксинга. но она пока закончилась неудачей.

мне кажется тут нужно ждать поддержки от ВМ, конечно можно усложнить компилятор и покрыть некоторые кейсы, но это только для частых кейсов

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

Вопрос не в unboxing, а в том что на втором скрине в строках 32, 33, 34 три раза происходит boxing. Если бы 26 строка разбивалась на 2 этапа:

val xyz = (A1)element$iv;
val it = xyz.unbox-impl();

то на 32, 33 и 34 можно было бы обойтись без boxing и использовать xyz:

f3(xyz);