Comments 24
Я конечно сейчас получу кучу минусов, но вот это:
String campPeople = sport.stream().filter(p -> p.getName() != null).map(SportsCamp::getName).collect(Collectors.joining(" and ",«In camp »," rest all days."));
ну ни как не легче для чтения кода, чем обычный цикл по коллекции. Особенно, конечно вставляют более сложные условия фильтров, чем проверка на нуль. Часто логика выбора и так слишком длинна и сложна, что приходится для читаемости разбивать на несколько строк/операторов.
String campPeople = sport.stream().filter(p -> p.getName() != null).map(SportsCamp::getName).collect(Collectors.joining(" and ",«In camp »," rest all days."));
ну ни как не легче для чтения кода, чем обычный цикл по коллекции. Особенно, конечно вставляют более сложные условия фильтров, чем проверка на нуль. Часто логика выбора и так слишком длинна и сложна, что приходится для читаемости разбивать на несколько строк/операторов.
0
Если добавить немного форматирования, то всё становится не так уж плохо:
String campPeople = sport.stream()
.filter(p -> p.getName() != null)
.map(SportsCamp::getName)
.collect(Collectors.joining(" and ",«In camp »," rest all days."));
+11
Так по моему лучше
String campPeople = sport.stream()
.filter(Objects::nonNull)
.map(SportsCamp::getName)
.collect(Collectors.joining(" and ",«In camp »," rest all days."));
Каждая строка описывает одну манипуляцию над стримом, что более очевидно передает логику. +2
Ну, минусов-то тут не за что. Нормальный вопрос, на нормальную (хотя и далеко не новую тему).
Попробую дать свой ответ.
Те кто думает, будто манипулирование коллекциями в таком стиле легче читается, как минимум лукавят. Для кого-то может и легче, но это дело субъективное. Вопросу тут не в легкости. Дело в другом — такой функциональный стиль удобнее компонуется, потому что по сути это функции, которые можно объединять в формулы, спокойно параллелить вычисления (если данные имутабельны и нет побочных эффектов), причем правильность компоновки в значительной степени за нас проверит компилятор.
>Часто логика выбора и так слишком длинна и сложна, что приходится для читаемости разбивать на несколько строк/операторов.
Вот это в сущности и есть цель. Чтобы можно было надежно разбивать и компоновать обратно, а части были максимально повторно используемыми.
Попробую дать свой ответ.
Те кто думает, будто манипулирование коллекциями в таком стиле легче читается, как минимум лукавят. Для кого-то может и легче, но это дело субъективное. Вопросу тут не в легкости. Дело в другом — такой функциональный стиль удобнее компонуется, потому что по сути это функции, которые можно объединять в формулы, спокойно параллелить вычисления (если данные имутабельны и нет побочных эффектов), причем правильность компоновки в значительной степени за нас проверит компилятор.
>Часто логика выбора и так слишком длинна и сложна, что приходится для читаемости разбивать на несколько строк/операторов.
Вот это в сущности и есть цель. Чтобы можно было надежно разбивать и компоновать обратно, а части были максимально повторно используемыми.
0
Еще одна статья про Stream API, коих было уже предостаточно. Описано как-то очень сумбурно. Для людей, имеющих опыт работы со стримами — ничего нового, а для новичков — ничего не понятно.
+1
Не могу принять Вашу точку зрения, т.к. она не подкреплена примерами.
Были комментарии выше, с которыми я полностью согласен, т.к. они аргументированы, но это не про Ваш комментарий.
Вы можете привести ссылки на огромное количество статей с работающими примерами за исключением уже имеющихся у меня в избранном?
В первых строках указано, что статья для пользователей начинающих знакомиться с данными возможностями, а не для профессионалов.
«Описано как-то очень сумбурно» — у всех свой стиль написания статей, замечу, что абсолютно все примеры рабочие и в точности показывают возможности функционала, а это немаловажно.
Были комментарии выше, с которыми я полностью согласен, т.к. они аргументированы, но это не про Ваш комментарий.
Вы можете привести ссылки на огромное количество статей с работающими примерами за исключением уже имеющихся у меня в избранном?
В первых строках указано, что статья для пользователей начинающих знакомиться с данными возможностями, а не для профессионалов.
«Описано как-то очень сумбурно» — у всех свой стиль написания статей, замечу, что абсолютно все примеры рабочие и в точности показывают возможности функционала, а это немаловажно.
0
Я не даю четкого определения и точного размера коллекций
~10000 (из книги Р. Уорбертона «Лямбда-выражения в Java 8»)
~10000 (из книги Р. Уорбертона «Лямбда-выражения в Java 8»)
0
У Вас будет точная формулировка этой цифры из книги? Возможно были дополнительные условия применения именно 10000?
0
Имеется в виду размер коллекции, при котором использование parallelStream действительно оправдано по производительности (поскольку, как известно, fork-join имеет некоторый оверхед на разделение/слияние потоков). Точную цитату могу поискать чуть позже. Ричард Уорбертон является одним из авторов-разработчиков данной технологии (и вообще Stream API), думаю, ему можно доверять. Книга небольшая, переведена на русский и есть в магазинах (и, к слову, в миллион раз полезнее, чем данная статья)
-1
Понятно, что речь идет про коллекцию, и про fork/join обсуждали. Вы напишите формулировку из книги, т.к. я еще раз повторю, что коллекции бывают разные(обратите на это внимание). Книга действительно хорошая. Про полезность статьи судить не Вам(возможно, что многим примеры будут полезны).
-1
Про полезность статьи судить не Вам(возможно, что многим примеры будут полезны).
Нам судить, читателям хабра. И, пожалуйста, воздержитесь от подобных формулировок, они сильно смахивают на хамство.
-1
Данная фраза относилась к пользователю afanasiy_nikitin. Мне кажется, что я обоснованно рассказал в комментариях ниже свою точку зрения. Еще раз повторю, что если мы заявляем о фактах из книг, то мы должны в этом быть уверены. Я не поленился и перечитал(уже почти полностью) данную книгу и написал, что afanasiy_nikitin не прав и в чем, привел выдержки из книги.
Кстати, книгу всем советую, действительно отличная.
Кстати, книгу всем советую, действительно отличная.
0
Не ищите цитату, т.к. вот она:
«При замере времени работы примеров 6.1 и 6.2 на 4-ядерной машине при 10 альбомах последовательная версия оказывается в 8 раз
быстрее. При 100 альбомах обе версии работают одинаково быстро,
а при 10 000 альбомов параллельная версия опережает последовательную в 2,5 раза.
Все результаты измерений в этой главе приводятся только для сведения. На вашей машине они могут оказаться совершенно другими.
Размер входного потока – не единственный фактор, определяющий, даст ли распараллеливание ускорение. Результаты могут также
зависеть от способа написания кода и количества доступных ядер.»
Автор книги Ричард Уорбэртон приводит нам пример про 10000(не говоря о том, что 10000 — это идеальное число для «отсечки») и обратите внимание, что скорости могут отличаться.
«При замере времени работы примеров 6.1 и 6.2 на 4-ядерной машине при 10 альбомах последовательная версия оказывается в 8 раз
быстрее. При 100 альбомах обе версии работают одинаково быстро,
а при 10 000 альбомов параллельная версия опережает последовательную в 2,5 раза.
Все результаты измерений в этой главе приводятся только для сведения. На вашей машине они могут оказаться совершенно другими.
Размер входного потока – не единственный фактор, определяющий, даст ли распараллеливание ускорение. Результаты могут также
зависеть от способа написания кода и количества доступных ядер.»
Автор книги Ричард Уорбэртон приводит нам пример про 10000(не говоря о том, что 10000 — это идеальное число для «отсечки») и обратите внимание, что скорости могут отличаться.
0
Речь идет о количестве порядков, я полагаю? Btw, я рад, что вы нашли книгу. Надеюсь, вы прочитаете ее целиком, и ваш код (и, может быть и эта статья) обогатится более точными и полезными примерами и комментариями. Спасибо за дискуссию.
0
1) Речь про значение в 10000 идет о альбомах (музыкальных треках).
2) Не могу понять Ваше желание сравнивать книги и статьи, приводя неправильные примеры, вводя в заблуждение читателей. Замечу. что автор книги(Ричард Уорбэртон), начиная со 107 страницы, подробно пишет о производительности при разных структурах и объемах данных. Вами сказанного значения в "~10000" у него нет.
3)Пожалуйста.
2) Не могу понять Ваше желание сравнивать книги и статьи, приводя неправильные примеры, вводя в заблуждение читателей. Замечу. что автор книги(Ричард Уорбэртон), начиная со 107 страницы, подробно пишет о производительности при разных структурах и объемах данных. Вами сказанного значения в "~10000" у него нет.
3)Пожалуйста.
0
Еще раз специально перечитал несколько глав из книги Герберта Шилдта пытаясь найти упоминание о пороговых значениях, не нашел. Пытался смотреть другие источники, не нашел. Есть особенности при обработке в параллель. Первое — мы зависим от мощностей и «свободных» процессоров. Второе — коллекции представляют из себя различную структуру, поэтому необходимы точные формулировки из Вашего примера для понимания возможностей в точности разделения коллекций по определенному пороговому значению.
0
Про 10000 — феерический бред. Ваша работа — это N*Q, где N — количество элементов, а Q — среднее время обработки элемента. Если Q очень велико, то распараллеливать имеет смысл уже при N = 2. Если Q исключительно мало (например, сложение двух чисел), то параллелизм поможет только при больших N. Кроме того, многое зависит от самих операций в стриме. Если все операции stateless, вы можете получить хороший прирост. Если имеются stateful-операции, можно сильно замедлиться даже для очень большого N. Переменных очень много.
+2
(p1,p2) -> p1.getDay().compareTo(p2.getDay())
Лучше писатьComparator.comparing(SportsCamp::getDay)
. Меньше вероятность ошибки.
+3
Sign up to leave a comment.
Немного о Stream API(Java 8)