A slightly different variant.
List<Rbs> cellList =
commonTest.values()
.stream()
.map(CommonPrep::getRbsList)
.flatMap(Collection::stream)
.collect(Collectors.toList());
As you can see, eventually you'll need to call the stream
method once in the .values().stream()
and N
times in the flatMap
(due to the return value of the function passed to flatMap
) where N
is the number of elements returned from the map
operation.
In fact, each intermediate operation also returns a Stream<T>
, so there are more stream objects than what I've mentioned above.
There's no way to avoid it. plus creating a stream, in general, is a cheap operation so you shouldn't be concerned about it.
Thus, unless you're experiencing performance issues it's better not to think about how many Stream objects are created and instead focus on writing your query to achieve what you want and let the library handle the rest.
Even, if you were experiencing performance issues trying to find ways to avoid creating new streams on each function call or method call is not going to work as all intermediate operations returns a new stream on each invocation and some operations accepting behavioral parameters also return new streams as in the function passed to flatMap
.
I very much doubt you're currently experiencing performance issues due to the creation of stream objects. Anyhow, you can always consider going parallel when you're experiencing performance problems.
It's important to understand several factors before even attempting to go parallel. You can read the answers here for things to consider.