(как я себе представляю работу трансдьюсера очень упрощённо разумеется):
val data
val result1 = mutCol()
var itr = data.iterator()
val test = {v -> v % == 0}
val transform = { v-> v*3 }
while (itr.hasNext() ) {
val v = itr.next()
if (test(v)) result1.add(transform(v))
}
Здесь всего одна итерация по коллекции - уже хотя-бы это должно быть быстрее и виртуальные вызовы лямбд это перекрывают по производительности?
kotlinc не может их заинлайнить при всем желании, JVM их может заинлайнить теоретически, но допустимость этого проверить трудно.
Ну предположим.. но разве виртуальные вызовы настолько дороги что даже двойная итерация по коллекции и создание промежуточных коллекций дешевле?
Если данные небольшие - да.
Ну в этом моя как бы мысль - данные они могут стать большими независимо от кода а виртуальные вызовы останутся какими были. Вчера было 10 пользователей в списке а завтра 1000 и вот уже виртуальный вызов на фоне двойной итерации и не кажется таким уж дорогим.
ну, а если пользователей станет 10^8, то их надо будет хранить в БД, так может сразу бд привязывать?)
смешно да, любую идею можно довести до абсурда
ну то ест я к тому, что архитектуру нужно самому продумывать
Бенчмарк говорит, что 1000 пользователей на сиквенсе срабатывают чуть хуже.
Если могут то можно и сиквенс. Не все данные простоттак вырастают
Обсуждают сегодня