StreamEx is a powerfull library but at some point I don't need its superpowers anymore.
How could I get rid of StreamEx internal overhead ? Could this pose a problem ?
Ex.
public void process(Path path){
StreamEx.of(Files.lines(path))
.groupRuns(...)
//See below
.unwrap()
//
.map(...)
.forEach(...)
}
There's no public API method to "unwrap" the
StreamEx
stream. This is done on purpose. In general theStreamEx
class is compatible with originalStream
API, so if you need to passStreamEx
to some code accepting simpleStream
, you can do this without any fear.The overhead of using
StreamEx
is usually very low: only one or several additional call per stream step (some of which could be eliminated by JIT compiler). This overhead (if not eliminated by JIT) appears only during the stream creation, not during evaluation, thus it does not depend on number of elements in the stream. When the terminal operation occurs, the processing is handed over to the original stream, thus in your example duringmap
andforEach
evaluation no StreamEx library code will be running.The
StreamEx
overhead might be somewhat significant if you create many simple short streams. For example, if you create theStreamEx
instance inside theflatMap
. So in this case if performance matters and you don't need specificStreamEx
operations for the nestedStream
, probably it's a good idea to avoidStreamEx
inside theflatMap
. Though according to my tests the difference become significant (say, more than 5%) only on very artificial cases.Note that some
StreamEx
operations are optimized compared to the Stream API equivalents. For example,StreamEx.toList()
is usually faster thanStream.collect(Collectors.toList())
. Simple create-map-collect operation likeStreamEx.of(persons).map(Person::getName).toList()
could work several times faster compared to thepersons.stream().map(Person::getName).collect(Collectors.toList())
.