Hi Will
On the question of parallel vs. sequential streams, Jason is certainly right that there needs to be sufficient parallelizable work to justify the overhead of splitting into parallel streams and later merging the results. It's quite a complicated question, though: you also have to take into account (amongst other things) how splittable the data source is and whether the intermediate operations are truly CPU-intensive.
Actually, the parallel/serial choice is going to be relatively uncommon in practice. More everyday gotchas arise from the design goals of the streams package, which assume that all stream programs are written so that they
could be executed in parallel, even if it doesn't happen to be worthwhile to do so. The requirements this imposes are documented in
the Stream package summary, under the headings "Non-interference", "Stateless behaviours", and "Side-effects".
I explain all this in the book. But it takes quite a few pages – more space than we have for answering questions on this forum
Regards
Maurice