Ну инхаус RMR может на Котлин фигачить. А именно заказную.

Откуда инфа?

Они это вроде не скрывают

Пруф: https://habrahabr.ru/company/redmadrobot/blog/321458/

а заказчикам разве не пофиг на чем вы делать будете?

@Enleur для заказчиков это вроде вообще первый пункт в тз

а вообще на главной котлина есть Who's using Kotlin и оттуда можно набрать имена компаний

Ну в том списке одни продуктовнеры же.

у нас тоже продуктовая...

что можно сделать в ситуации, когда при компиляции андроид проекта получаю "Error:(1, 1) Some error(s) occurred while processing annotations. Please see the error messages above." и никаких сообщений выше нет. только название класса. но в нем вообще нет особых аннотаций, кроме JvmStatic?

скорее всего проблема в даггере, так как его граф менялся перед этим. но есть ли способ узнать в каком месте проблема?

посмотрел код этих перфоманс-тестов, которые выше фигурировали, переписал на котлинвей, получилось что-то вроде такого, но работает и правда медленнее джавы, кто без профайлера скажет почему: fun calculateFF(signals: Array<Signal>, population: Array<Individual>, valueFactor: Int): Int { return population.sumBy { (lower, upper) -> signals.sumBy { (variables, value1) -> val passed = variables .allIndexed { index, value -> value in lower[index].. upper[index] } if (passed && valueFactor == 1) value1 else 0 } } } inline fun IntArray.allIndexed(predicate: (Int, Int) -> Boolean): Boolean = indices.all { predicate(it, get(it)) }у меня из вариантов только итераторы пока

lower[index].. upper[index] не?

или он прям умно оптимизирует это?

не, это не влияет

https://github.com/JetBrains/kotlin/blob/1.1.0/core/builtins/src/kotlin/Ranges.kt#L54 хотя да, он умный

ни у кого нет хороших мыслей? наверное стоит профайлер запустить всё-таки

посмотрел код этих перфоманс-тестов, которые выше фигурировали, переписал на котлинвей, получилось что-то вроде такого, но работает и правда медленнее джавы, кто без профайлера скажет почему: fun calculateFF(signals: Array<Signal>, population: Array<Individual>, valueFactor: Int): Int { return population.sumBy { (lower, upper) -> signals.sumBy { (variables, value1) -> val passed = variables .allIndexed { index, value -> value in lower[index].. upper[index] } if (passed && valueFactor == 1) value1 else 0 } } } inline fun IntArray.allIndexed(predicate: (Int, Int) -> Boolean): Boolean = indices.all { predicate(it, get(it)) }у меня из вариантов только итераторы пока

А он в java8 скомпилирован?

аха

аха

?

А он в java8 скомпилирован?

а что компилировать в Java8 разве есть какие-то профиты?

а что компилировать в Java8 разве есть какие-то профиты?

лямбды через invoke-dynamic?

компилятор другой

лямбды через invoke-dynamic?

а это разве уже привернули?

компилятор другой

другой чем какой?

лямбды через invoke-dynamic?

там одна лямбда же

лямбды через invoke-dynamic?

да и нету там лямбды ниодной

вообще пофиг

да и нету там лямбды ниодной

кложур?

кложур?

это чят про котлин вроде

замыкание

не язык

замыкание

нету там ниодно ни замыкания ни лямбды ни кложуры

посмотрел код этих перфоманс-тестов, которые выше фигурировали, переписал на котлинвей, получилось что-то вроде такого, но работает и правда медленнее джавы, кто без профайлера скажет почему: fun calculateFF(signals: Array<Signal>, population: Array<Individual>, valueFactor: Int): Int { return population.sumBy { (lower, upper) -> signals.sumBy { (variables, value1) -> val passed = variables .allIndexed { index, value -> value in lower[index].. upper[index] } if (passed && valueFactor == 1) value1 else 0 } } } inline fun IntArray.allIndexed(predicate: (Int, Int) -> Boolean): Boolean = indices.all { predicate(it, get(it)) }у меня из вариантов только итераторы пока

А в java не через paraller-stream делается случаем ??

А что за абстракция тогда {(lower, apper) -> ?

А в java не через paraller-stream делается случаем ??

у джавы там пайп получается да

А в java не через paraller-stream делается случаем ??

не, там прямо голыми циклами

Но не уверен что в этом дело

А что за абстракция тогда {(lower, apper) -> ?

это всё заинлайнено

Я не котлиновод но у котлина тоже есть пайп-вей

не помню точно какой

это всё заинлайнено

это не отменяет абстракции

Я не котлиновод но у котлина тоже есть пайп-вей

так вот я же написал настолько пайпно насколько смог

это не отменяет абстракции

отменяет если мы говорим про перфоманс

ну тогда есть веростность что вас не поймут =)

не, там прямо голыми циклами

как ты это проверяешь?

как ты это проверяешь?

https://github.com/doomviruz/PerfTests/blob/master/Java/src/com/company/Test.java#L52

код смотрю

посмотрел код этих перфоманс-тестов, которые выше фигурировали, переписал на котлинвей, получилось что-то вроде такого, но работает и правда медленнее джавы, кто без профайлера скажет почему: fun calculateFF(signals: Array<Signal>, population: Array<Individual>, valueFactor: Int): Int { return population.sumBy { (lower, upper) -> signals.sumBy { (variables, value1) -> val passed = variables .allIndexed { index, value -> value in lower[index].. upper[index] } if (passed && valueFactor == 1) value1 else 0 } } } inline fun IntArray.allIndexed(predicate: (Int, Int) -> Boolean): Boolean = indices.all { predicate(it, get(it)) }у меня из вариантов только итераторы пока

я думал контекст – вот этот код

не, контекст там был выше

тут ссылочку дали на типа перфоманс тесты https://github.com/doomviruz/PerfTests/ конечно тестами это назвать сложно, но в целом интересно за счет чего джава (ссылка на код немного выше) выигрывает чуть ли не в двое у того кода, что написал я немного выше

inline fun <T> Array<out T>.sumBy(selector: (T) -> Int): Int { var sum: Int = 0 var i = 0 while (i < size) { sum += selector(get(i)) i++ } return sum } inline fun IntArray.allIndexed(predicate: (Int, Int) -> Boolean): Boolean { var i = 0 while (i < size) { if (!predicate(i, get(i))) return false i++ } return true }

решило сразу все проблемы

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

это просто такие тесты или реально котлин медленее?

вообще в стдлиб-е для массивов можно было бы сделать и вот такие реализации

и как это может повлиять при написании серверных аппликейшенов?

решило сразу все проблемы

Я это еще в своей LibGDX игре заметил, что Kotlin foreach внутри foreach создает кучу интераторв и грузит GC (а на старых Android с GC совсем плохо)

это просто такие тесты или реально котлин медленее?

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

Я это еще в своей LibGDX игре заметил, что Kotlin foreach внутри foreach создает кучу интераторв и грузит GC (а на старых Android с GC совсем плохо)

в либгдх надо использовать местные коллекции без выхлопа

inline fun <T> Array<out T>.sumBy(selector: (T) -> Int): Int { var sum: Int = 0 var i = 0 while (i < size) { sum += selector(get(i)) i++ } return sum } inline fun IntArray.allIndexed(predicate: (Int, Int) -> Boolean): Boolean { var i = 0 while (i < size) { if (!predicate(i, get(i))) return false i++ } return true }

написать к ним экстеншены и наслаждаться

это, Борис, да?

это, Борис, да?

в обычной жизни это конечно не особо играет

но если надо по пефомансу удолбаться, то может очень даже

в либгдх надо использовать местные коллекции без выхлопа

Да да, надо их вообще в Kotlin добавить вместо Java коллекций - что-бы не тормозил ?

ERROR: S client not available

в обычной жизни это конечно не особо играет

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

Да да, надо их вообще в Kotlin добавить вместо Java коллекций - что-бы не тормозил ?

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

все равно обычно все в бд и диск упирается

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

скорее всего нет

все равно обычно все в бд и диск упирается

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

это просто такие тесты или реально котлин медленее?

в оригинальном сравнении когда заявляли что он медленнее в 3-4 раза уже нашли ошибку и теперь разницы нет

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

главное не на го

или скале

у них на таком бенчмарке проблемы серьезные)

в оригинальном сравнении когда заявляли что он медленнее в 3-4 раза уже нашли ошибку и теперь разницы нет

реально из за итераторов почти вдвое медленнее по моим замерам получилось

после замены на while всё стало летать

еще быстрее чем на джаве

у них на таком бенчмарке проблемы серьезные)

А у них там иммутабельные коллекции используются?

там конечно погрешность очень большая, так что 10% не имеет смысл считать разницей

главное не на го

а чем го для такого теста плох? должно летать мама не горюй

А у них там иммутабельные коллекции используются?

можешь исходники глянуть. но вроде как везде примитивы https://github.com/doomviruz/PerfTests/blob/master/Scala/src/Test.scala

а чем го для такого теста плох? должно летать мама не горюй

на таком тесте го себя не очень показал

на таком тесте го себя не очень показал

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

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

в оригинальном сравнении когда заявляли что он медленнее в 3-4 раза уже нашли ошибку и теперь разницы нет

ребят, а в чем ошибка была?

кто шарит, поясните пожалуйста

ребят, а в чем ошибка была?

Array<Int> юзали вместо IntArray, из-за этого оверхед с боксингом был

ребят, а в чем ошибка была?

Array<Int> вместо IntArray

такие тонкости откуда можно узнать? в доках котлина описывается?

можешь исходники глянуть. но вроде как везде примитивы https://github.com/doomviruz/PerfTests/blob/master/Scala/src/Test.scala

Я думаю если переписать эти красивые for на which с индексом будет так же быстро и не идиоматично

такие тонкости откуда можно узнать? в доках котлина описывается?

да kotlinlang.org/docs/reference/basic-types.html#arrays

компилятор котлина сам умеет Int в примитивы гонять, но не в случае с массивом

Я думаю если переписать эти красивые for на which с индексом будет так же быстро и не идиоматично

?

это фанаты гошечки просили этот тест. им дали, но пока молчат. заряжают страшные вещи типа >если использовать средства языка и использовать горутины, время уменьшается в ~3 раза — play.golang.org/p/PO6KeoAt7z плюс если обьявлять структуру не с массивами, а срезами и потом их инициализировать отдельно, то у меня выигрыш еще ~20 сек вышел — play.golang.org/p/wiKY4tEyYo. Меняется расположение массива. Уже не часть структуры, а указатель на него. Хотя так как потом передается слайс в функцию, а не массив, то по идее разницы не должно быть. Но тут надо профилировать

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

Я думаю если переписать эти красивые for на which с индексом будет так же быстро и не идиоматично

почему это не сделали в stdlib авторы?)

?

а, понял. так я же так и сделал