Комментарии 12
??
Классная статья! Очень познавательно.
Жаль что нет сравнения с ручным преобразованием списком, без удобных операторов котлина. Был бы значительный прирост в производительности, если не было лишних созданий списков?
Ты имеешь в виду объединить все функции преобразования в одну большую лямбду и прогнать ее в рамках одного прохода по циклу?
В таком случае мы еще немного выиграем, но мне сложно представить код этой монструозной лямбды. И не очень понятно, как в ней делать такие операции как фильтр, агрегация, zip.
У функций расширений коллекций очень удобный интерфейс, которые позволяет их просто и лаконично использовать и связывать друг с другом. И мне кажется в большинстве случаев лаконичность и читаемость кода намного важнее небольшого выигрыша в производительности. А sequences как раз хороши тем, что повторяют этот интерфейс, но при этом дают нам еще немного профита.
Скорее не лямбду для какой-то extension-функции, а обработку в едином for-цикле. Такой код явно не будет очень удобным для чтения и выглядить будет так себе, но интересно именно какой оверхед несут extension-функции для списков. Все же каждая такая функция создает новый список и более сложные преобразования. Таким вопросом давно задаюсь, но сам так и не проверил.
Но даже не смотря на результаты переставать пользоваться этими удобными функциями не перестану, с ними код чище и более читаем.
Спасибо, очень познавательно! Но возник вопрос, по цифрам похоже даже тяжёлые преобразования (flatten/sort) не так и плохи, если не применять их в коротких цепочках. Либо нет? Я имею в виду, что сиквенс предлагается применять, если цепочка длинная, и в ней тяжёлое преобразование скорее всего будет одним шагом из многих, и рост от его применения возможно будет нивелирован выигрышем на других шагах. Безусловно это никак не оспаривает того, что хорошо, что оно будет исправлено...
В том то и дело, что эти три операции sort, flatten, plus тяжелые и проигрыш от применения одной из них вы не компенсируете даже 10 дополнительными преобразованиями. Посмотрите на абсолютное время выполнения операции и сравните его с другими операциями.
В процентах он выглядит не так катастрофично, но в абсолютных цифрах он выглядит как приговор.
И тесты преобразований из кода реального проекта подтверждают это. Я не писал об этом в статье, но это есть в видео с доклада на мобиус.
Но я как раз от цифр статьи отталкивался - выигрыш на 5 операциях map при листе в 100 - примерно 30к нс, проигрыш от 1 sort - те же 30к нс. Плюс-минус тоже самое. Хотя флаттен и плюс конечно сильно дольше...
Да, пожалуй вы правы. В случае сортировки 5 преобразований map в среднем как раз дают нам компенсационный выигрыш, чтобы нивелировать проигрыш от сортировки.
Но в реальной жизни я редко видел в коде преобразования, где количество функций было больше 5. Если быть точным, то в нашем проекте (а он довольно большой) я нашел только одно преобразование из семи функций.
В среднем, все преобразования укладываются в 4-5 функций. А в этом случае, при использовании сортировки, вы скорее всего проиграете коллекциям.
Написано настолько легко и четко, что даже на категорию Сложный не тянет:). Наверное лучшее, что я в принципе читал на тему коллекции vs sequence.
Измеряя sequences