Hi Peter, You are correct in stating that flatMap has some overhead.
There are optimizations in place for operating on one element and on the head of the stream that reduce the overhead. Escape analysis sometimes works, it would be nice if that were more reliable, and of course similar things apply to creation of Optional instances. I hope that will improve post 9. There are also much more important performance issues, especially related to profile pollution, that we may need to solve via loop specialization. Ideally i really want to avoid explicit fusing of operations in the API for performance reasons. It should be up to the implementation/compiler to work that out. It's helpful to quantify as you have done for the performance sensitive of us. We did ponder those methods you suggested. Note that the primitive variants also need to be considered too. The first, filterMap, is not value type friendly. Rather than adding the second, mapOptionally, we added Optional.stream to be used with flatMap :-) Paul.
