TT
joinToString может быть и объединит их по умному, не создавая промежуточные строки
Size: a a a
2019 October 15
TT
ну фигня то фигня, но это ведь значит что первый вариант значительно производительнее если считать в процентом соотношении
AN
joinToString может быть и объединит их по умному, не создавая промежуточные строки
там тот же самый StringBuilder
TT
а так , я просто заморочился, хочу знать как лучше будет, если эту функцию надо в биг дата юзать
TT
ясно, значит он снова все строки разобьет в массив char потом в байты, а потом сделает строку)
AN
а так , я просто заморочился, хочу знать как лучше будет, если эту функцию надо в биг дата юзать
Бигдата - это сколько?
AN
ясно, значит он снова все строки разобьет в массив char потом в байты, а потом сделает строку)
Ну там сильно заоптимизируется.
TT
Бигдата - это сколько?
в моем случае ничего нет, копейки. А вообще может я хочу транслитироцию провести гигабайтами текста
AN
в моем случае ничего нет, копейки. А вообще может я хочу транслитироцию провести гигабайтами текста
Просто это называется преждевременная оптимизация и сильно осуждается. Это я вам как человек, работающий с performance sensitive кодом говорю.
AN
buildString + forEach вполне нормальный вариант
TT
Просто это называется преждевременная оптимизация и сильно осуждается. Это я вам как человек, работающий с performance sensitive кодом говорю.
знаю, я просто для себя хочу знать это, я учился начиная с qbacic и поэтому мне интересно как это под капотом работает
TT
buildString{} сейчас глянуAN
знаю, я просто для себя хочу знать это, я учился начиная с qbacic и поэтому мне интересно как это под капотом работает
JVM сильно оптимизирует все, часло сложно понять, что лучше. Вообще единственный критерий - профайлер
TT
JVM сильно оптимизирует все, часло сложно понять, что лучше. Вообще единственный критерий - профайлер
ну это да. Раз начали эту тему, еще хотел бы спросить насчет соединения строк. Почему когда мы это делаем в цикле, то комплилятор не оптимизирует используя StringBuilder, а вне цикла оптимизирует?
AN
ну это да. Раз начали эту тему, еще хотел бы спросить насчет соединения строк. Почему когда мы это делаем в цикле, то комплилятор не оптимизирует используя StringBuilder, а вне цикла оптимизирует?
Потому что не настолько умный. Когда все рядом, это просто интринсик. А если в цикле, то тут понять, как вы будете это использовать уже сложно.
TT
Потому что не настолько умный. Когда все рядом, это просто интринсик. А если в цикле, то тут понять, как вы будете это использовать уже сложно.
понял спасибо и за
StringBuilder{} спасибоQH
sidenote: котлин создаёт StringBuilder даже для конкатенации двух строк, хотя String.concat было бы эффективнее
VP
Я бы для начала написал читаемый код, а потом уже думал о производительности 😄
AN
Я бы для начала написал читаемый код, а потом уже думал о производительности 😄
Даже не читаемый, а правильно организованный. И это надо вбивать в головы всем гонщикам за производительностью
IM
Привет. Я как не искушенный джавой поймал "NaN".toDoubleOrNull(). Починил через "NaN".toDoubleOrNull()?.takeIf { !it.isNaN() }. Подскажите, есть ли еще похожие приколы, когда я ожидаю чисел а получу нечто другое?