Comments 13
А с занимаемой памятью что?)
Для начала - где blackHole? Дальше в принципе можно не обсуждать.
Второе - Java предназначена для энтерпрайза. В энетрепрайзе в стримы никогда не передаются массивы на тысячи и миллионы объектов. Подавляющее большинство - порядка десятка. У клиента не может быть тысячи счетов. История занимает три-четыре периода. И так далее. И везде стримы на таких маленьких массивчиках. Почему автор не сравнил обработку массивов на десять чисел? Нелицеприятные результаты не в пользу стримов?
У клиента не может быть тысячи счетов
А энтерпрайз это только про клиентов и счета? Навскидку (из того, с чем я работал) в телекоме могут быть связи аккаунт - телефонные номера с сотнями тысяч номеров. Временные ряды со статистикой проездов по федеральной трассе - миллионы записей. Трейдинг - сотни тысяч котировок. Ну да, другой вопрос, что в коллекции все сразу они не окажутся. А то OOM будет.
Нелицеприятные результаты не в пользу стримов?
Так видно же, что как раз на малой коллекции форыч быстрее. Что у вас "власти скрывают"-то? И автор как раз радуется, что стримы не настолько плохи, чтобы был резон от них оказываться.
Какой-нибудь gitlab или appscreener под капотом тоже джаву содержат, которая потоково обрабатывают код. Там есть "жирненькие" места, которые могли бы получить буст по перформансу от перехода на что-то производительное.
Для начала - где blackHole?
«Когда в руки попадает чёрная дыра, перестаёшь замечать происходящее за горизонтом событий.»
Оно здесь не надо. Результат вычислений возвращается из забенчмаркленных методов во внешний мир.
Current infrastructure generates the synthetic code that runs
@Benchmarkin a specially-constructed loop, and consumes the results into the Blackhole.https://mail.openjdk.org/pipermail/jmh-dev/2016-August/002294.html
У Шипилёва в древних заметках, при желании, можно найти аналогичные утверждения.
A Blackhole is used when it is not convenient to return a single object from a benchmark method. This happens when the benchmark produces several values, and we want to make sure that the virtual machine will not speculate based on the observation that the benchmark code does not make use of these.
https://www.oracle.com/technical-resources/articles/java/architect-benchmarking.html
Java предназначена для энтерпрайза.
Java всю жизнь была Write Once Run Anywhere, не нужно тут этих ваших когнитивных искажений.
В энетрепрайзе в стримы никогда не передаются массивы на тысячи и миллионы объектов.
И SELECT * FROM ... тоже никто никогда не делает, да ;)
Нелицеприятные результаты не в пользу стримов?
Не смог распарсить предложение, извините.
нелицеприя́тный
Прилагательное, качественное
Беспристрастный, справедливый.
Спасибо! Интересная статья!
1000000 Integers из бенчмарка влезут в кэш современных процессоров, тогда как в реальном приложении, скорее всего, читаться они будут не из кэша. В таком случае int (размер 4 байта) вместо Integer (24 байта) должен быть быстрее, но стримы с ним работать не умеют.
Перформанс :)
Думаю forEach можно было бы улучшить если бы использовался обычный for, он бы не создавал лишний объект итератор.
Еще раз о перформансе стримов в Java