Извините, но в том виде, в котором вы сформулировали вопрос, он выглядит как поток сознания, вырваный из контекста. Те, кто здесь присутствуют не в курсе вашего контекста, естественно ничего не поняли. Постарайтесь ответить для начала на вопрос, какую проблему решаете (что на входе, что хотите с этим сделать).

+

https://medium.com/@programmerr47/to-index-or-iterate-7b81039e5484 еще про андроид

в jmh получается одинаково indexed\iterator, мб что то не так делаю офк, ну сорян

Не в тему вопрос: а какая мотивация была выпилить из котлина статик?

Полного ответа не знаю, но статики это процедурщина, и вместо ооп мы возвращаемся к процелурам, тот же апач комонс

# Run complete. Total time: 00:01:43 Benchmark (iterations) Mode Cnt Score Error Units BenchMark.indexed 20 thrpt 20 983.198 ± 52.642 ops/s BenchMark.iterator 20 thrpt 20 921.769 ± 18.794 ops/s

я так то парень с андроида, не в тот чат зашел

Не в тему вопрос: а какая мотивация была выпилить из котлина статик?

Однородность языка. Статики же WTF немного.

у большой джавы жит то получше соображает

Не в тему вопрос: а какая мотивация была выпилить из котлина статик?

статик из джавы разлетелся в как минимум две стороны - в компаньон обжекты и в переменные\функции на уровне файла

статик из джавы разлетелся в как минимум две стороны - в компаньон обжекты и в переменные\функции на уровне файла

Знаю

гуд

Однородность языка. Статики же WTF немного.

wtf немного это объявление static переменных внутри метода, а в джаве то норм)

Чот трасляция походу подсдохла

Господи, бенчмаркать forEach по листам и сравнивать его со старым for с доступом по индексу. Тут в первую очередь нужно посмотреть в байт-код и убедиться что там один и тот же код сгенирировался, и перестать вообще думать о таких микрооптимизациях

+, а потом еще и jit пережует и дичь высокопроизводительную выплюнет

Чот трасляция походу подсдохла

Это только у меня?

Господи, бенчмаркать forEach по листам и сравнивать его со старым for с доступом по индексу. Тут в первую очередь нужно посмотреть в байт-код и убедиться что там один и тот же код сгенирировался, и перестать вообще думать о таких микрооптимизациях

почему перестать если прирост может дать существенный?

конечно не как замена стрим апи на циклы, но все же

почему перестать если прирост может дать существенный?

В том то и дело что не может. Или у тебя на андроиде бигдата считается?

wtf немного это объявление static переменных внутри метода, а в джаве то норм)

Это где такое?

В том то и дело что не может. Или у тебя на андроиде бигдата считается?

обычная дата становится бигдатой для бюджетных девайсов

Это где такое?

в objc

Это только у меня?

а всё, зашовелилось

Господи, бенчмаркать forEach по листам и сравнивать его со старым for с доступом по индексу. Тут в первую очередь нужно посмотреть в байт-код и убедиться что там один и тот же код сгенирировался, и перестать вообще думать о таких микрооптимизациях

Там не один и тот же код. Иногда обилие итераторов — это действительно проблема для GC, особенно в подписках/событиях/реактивщине.

обычная дата становится бигдатой для бюджетных девайсов

Ну щаз бюджетные девайсы, разве что имею траблы с дисковым IO, а остальное обычно быстро

для QueryDSL

Jooq

Ну щаз бюджетные девайсы, разве что имею траблы с дисковым IO, а остальное обычно быстро

ну такое

ну кстати не так уж и плохо, имеют более узкий скоуп, а это хорошо

зачем делать сравнения на одной ВМ, если запускать будешь на другой?

Android не имеет ничего общего с jvm же ?

Android не имеет ничего общего с jvm же ?

так я вроде именно на это и намекаю

Ну раз тут и так где-то об этом: енумы то юзаете в андроеде? =)

Ну раз тут и так где-то об этом: енумы то юзаете в андроеде? =)

Конечно. Они же офигительны.

Конечно. Они же офигительны.

и в адаптере как вью тайп? =)

Конечно. Они же офигительны.

А нада int

и в адаптере как вью тайп? =)

Ну не. В domain.

и в адаптере как вью тайп? =)

да классно

полиморфный парсинг, например

да, за такое надо канделябрами бить... https://github.com/JetBrains/kotlin/blob/f069686a14ca3c1c98adc04719f1a9045911ac3f/libraries/tools/kotlin-gradle-plugin/src/main/kotlin/org/jetbrains/kotlin/gradle/internal/kapt/KaptWithKotlincTask.kt#L82

А ведь могли просто взять VersionNumber из Gradle API

да классно

в адаптере красиво, но вот там как раз лучше инты =)

Ну раз тут и так где-то об этом: енумы то юзаете в андроеде? =)

Надо дождаться inline enum class

в адаптере красиво, но вот там как раз лучше инты =)

но черт побери, удобно жеж

Надо дождаться inline enum class

И как там реализовать полиморфизм?

И как там реализовать полиморфизм?

Хз. Ну а вообще я бы не стал разменивать базовые возможности языка (foreach, enum) на микрооптимизации.

Хз. Ну а вообще я бы не стал разменивать базовые возможности языка (foreach, enum) на микрооптимизации.

Правда в том, что enum нельзя втупую заменить IntDef'ом. Это другой инструмент. В вырожденных случаях, когда это сделать просто, ProGuard это делает.

но черт побери, удобно жеж

Да, но уж больно часто придётся создавать енум из инта

Да, но уж больно часто придётся создавать енум из инта

не нужно создавать

только искать только

только искать только

Мапа с енумами? ?

как viewtype передаешь ordinal и поиск быстрый

как viewtype передаешь ordinal и поиск быстрый

куда передаёшь?)

А обратно как? ValueOf?

Блин. Любители микрооптимизаций в красной зоне потери читабельности кода. Вы вообще прикидывали, на каких объёмах данных ваши микрооптимизации начинают хоть какую-то роль играть? Если надо много и быстро считать (Big Data), то там через массовый параллелизм производительность добирается, а не через Int VS enum и прочие микрохаки.

Блин. Любители микрооптимизаций в красной зоне потери читабельности кода. Вы вообще прикидывали, на каких объёмах данных ваши микрооптимизации начинают хоть какую-то роль играть? Если надо много и быстро считать (Big Data), то там через массовый параллелизм производительность добирается, а не через Int VS enum и прочие микрохаки.

Мы про андроед и скорость работы UI

@kotlin_mobile

Блин. Любители микрооптимизаций в красной зоне потери читабельности кода. Вы вообще прикидывали, на каких объёмах данных ваши микрооптимизации начинают хоть какую-то роль играть? Если надо много и быстро считать (Big Data), то там через массовый параллелизм производительность добирается, а не через Int VS enum и прочие микрохаки.

да в ui всегда играет

ну а читаемость дело наживное, посмотри код телеги, а работает класс

values() выделяет новый массив ;)

values() выделяет новый массив ;)

ну создай его один раз

ну создай его один раз

И уже сразу не так красиво

И уже сразу не так красиво

не, можно норм сделать

не, можно норм сделать

Можно

values() выделяет новый массив ;)

инфа проверенная кстати?

enum class Whatever { A, B, C; companion object { private val vals = values() operator fun get(ordinal: Int) = vals[ordinal] } }

ERROR: S client not available

инфа проверенная кстати?

146%, там $VALUES.clone()

146%, там $VALUES.clone()

ок, спасибо не знал

enum class Whatever { A, B, C; companion object { private val vals = values() operator fun get(ordinal: Int) = vals[ordinal] } }

Ну да, ни чо так

да в ui всегда играет

Насчёт всегда играет - точно бред. Никакой фактор ни в какой области не является абсолютно решающим. На сколько процентов использование Int вместо enum ускоряет отклик вашего UI приложения? Насколько существенно для пользователя это ускорение отклика? Насколько горячий код с Int вместо enum в вашем UI приложении? Без ответов на эти вопросы нет смысла говорить, что от оптимизации есть хоть какая-то польза, кроме вреда.

Насчёт всегда играет - точно бред. Никакой фактор ни в какой области не является абсолютно решающим. На сколько процентов использование Int вместо enum ускоряет отклик вашего UI приложения? Насколько существенно для пользователя это ускорение отклика? Насколько горячий код с Int вместо enum в вашем UI приложении? Без ответов на эти вопросы нет смысла говорить, что от оптимизации есть хоть какая-то польза, кроме вреда.

да ты прав конечно, аккуратнее сказать - может играть

Тут есть один нюанс: любое приложение всегда стартует слишком долго. Поэтому выпиливать лишние классы бывает полезно.

Ну может играть - очевидно, может. Как и в Big Data, и в High Load и в любой другой области. Я категорически против подхода: "оптимизируем всё и везде на скорость по максимуму". Надо идти по приоритетам: 1. Код должен быть корректным. 2. Если код корректный, но не укладывается в требования по производительности - выявляем узкие места и оптимизируем их.

Ну может играть - очевидно, может. Как и в Big Data, и в High Load и в любой другой области. Я категорически против подхода: "оптимизируем всё и везде на скорость по максимуму". Надо идти по приоритетам: 1. Код должен быть корректным. 2. Если код корректный, но не укладывается в требования по производительности - выявляем узкие места и оптимизируем их.

+

Ну это всё более-менее очевидно, да.

но после пары\тройки\десятка таких итераций человек сразу может начать писать страшный оптимизированный код в каких-то рамках

Тут есть один нюанс: любое приложение всегда стартует слишком долго. Поэтому выпиливать лишние классы бывает полезно.

Оптимизация старта и оптимизация времени отклика - это вообще разные задачи. При этом зачастую противоречивые. Можно динамически подгружать приложение, при этом стартовать оно будет быстро, а вот отклик может пострадать.

и ему норм будет

но после пары\тройки\десятка таких итераций человек сразу может начать писать страшный оптимизированный код в каких-то рамках

Только пишет он его очень близко к пределу сложности, которой может управлять. Если он при этом ещё и семи пядий во лбу, то те, кто с ним в команде, запросто перестанут понимать этот код и такой код уже можно считать неуправляемым с точки зрения команды. Человек заболел/в отпуске/уволился/умер и всё, что он писал можно только использовать как есть и переписывать по мере возможности, так как разобраться в этом кроме него никто не может.

Только пишет он его очень близко к пределу сложности, которой может управлять. Если он при этом ещё и семи пядий во лбу, то те, кто с ним в команде, запросто перестанут понимать этот код и такой код уже можно считать неуправляемым с точки зрения команды. Человек заболел/в отпуске/уволился/умер и всё, что он писал можно только использовать как есть и переписывать по мере возможности, так как разобраться в этом кроме него никто не может.

Это какой-то совсем вырожденный случай, оптимальный код — не обязательно говнокод.

Вот заведу я особый случай HashSet для Long, и будет у него интерфейс как у Set — кому это мешает?

Только пишет он его очень близко к пределу сложности, которой может управлять. Если он при этом ещё и семи пядий во лбу, то те, кто с ним в команде, запросто перестанут понимать этот код и такой код уже можно считать неуправляемым с точки зрения команды. Человек заболел/в отпуске/уволился/умер и всё, что он писал можно только использовать как есть и переписывать по мере возможности, так как разобраться в этом кроме него никто не может.

ну разобраться можно всегда, и еще сложный вопрос выгодно ли такой подход сотруднику\работодателю

Это какой-то совсем вырожденный случай, оптимальный код — не обязательно говнокод.

Оптимизация почти всегда усложняет код. Исключение - ошибки в исходной имплементации, которые привели к усложнению и просадке производительности одновременно.

Вот заведу я особый случай HashSet для Long, и будет у него интерфейс как у Set — кому это мешает?

Ну наличие двух сущностей уже сложнее, чем одна. Либо специализированный HashSet не будет использоваться, либо каждый раз при использовании придётся принимать на одно решение больше. Каждое такое решение - потенциальная ошибка.

ну разобраться можно всегда, и еще сложный вопрос выгодно ли такой подход сотруднику\работодателю

Ага. То-то все в квантовой физике разбираются, топологии, цифровой схемотехнике и прочих научных/инженерных дисциплинах. Разобраться - это всегда время, усилия, мотивация и мозги, зачастую большие. Если чего-то из этого не хватит - разобраться нельзя.

ну разобраться можно всегда, и еще сложный вопрос выгодно ли такой подход сотруднику\работодателю

Вы же учились в ВУЗе. Должны помнить, как скрипели и плавились мозги, притом на базовых понятиях. Да и из программирования: половина, если не больше пытающихся изучить чистое типизированное ФП умирает на таких базовых понятиях теории категорий, как функтор и монада.

Вы же учились в ВУЗе. Должны помнить, как скрипели и плавились мозги, притом на базовых понятиях. Да и из программирования: половина, если не больше пытающихся изучить чистое типизированное ФП умирает на таких базовых понятиях теории категорий, как функтор и монада.

не все =)

не все =)

В смысле не все учились в ВУЗе?

В смысле не все учились в ВУЗе?

да

Вы же учились в ВУЗе. Должны помнить, как скрипели и плавились мозги, притом на базовых понятиях. Да и из программирования: половина, если не больше пытающихся изучить чистое типизированное ФП умирает на таких базовых понятиях теории категорий, как функтор и монада.

Да конечно, но какие то базовые оптимизации с отказом от сахара могут дать много в перформкнсе но будут просто verbose. Вообщем зависит

Да конечно, но какие то базовые оптимизации с отказом от сахара могут дать много в перформкнсе но будут просто verbose. Вообщем зависит

Много — это сколько?

Много — это сколько?

Зависит

От немного до много

?

Да конечно, но какие то базовые оптимизации с отказом от сахара могут дать много в перформкнсе но будут просто verbose. Вообщем зависит

Пример просто verbose из литературы: "Война и мир". Надеюсь все помнят ощущения ?

Оптимизация ради оптимизации это почти всегда плохо. Почти любая оптимизация - это специализация. А специализация - это ограничения.

Андрей, вернёмся к тому с чего я тут за енумы начал, вот есть сущьность которая на основе данных генерирует вьшки для отображения в списке, каждый итем списка имеет тип представленый интом, вьюшки созданные попадают в пул и реюзаются, при быстрой прокрутке метод биндинга данных к вью вызывается очень часто. Вот и спрашивается использовать ли енум в такой ситуации для представления типа вьюшки при условии что проход gc вызовет "заикание" при прокрутке списка =) при этом оптимизацией (в сторону читаемости удобности написания) тут выглядит использование енума, по умолчанию все делают набор инт констант

Андрей, вернёмся к тому с чего я тут за енумы начал, вот есть сущьность которая на основе данных генерирует вьшки для отображения в списке, каждый итем списка имеет тип представленый интом, вьюшки созданные попадают в пул и реюзаются, при быстрой прокрутке метод биндинга данных к вью вызывается очень часто. Вот и спрашивается использовать ли енум в такой ситуации для представления типа вьюшки при условии что проход gc вызовет "заикание" при прокрутке списка =) при этом оптимизацией (в сторону читаемости удобности написания) тут выглядит использование енума, по умолчанию все делают набор инт констант

так а где тормоза от enum в этой ситуации?