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
StreamExstream. This is done on purpose. In general theStreamExclass is compatible with originalStreamAPI, so if you need to passStreamExto some code accepting simpleStream, you can do this without any fear.The overhead of using
StreamExis 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 duringmapandforEachevaluation no StreamEx library code will be running.The
StreamExoverhead might be somewhat significant if you create many simple short streams. For example, if you create theStreamExinstance inside theflatMap. So in this case if performance matters and you don't need specificStreamExoperations for the nestedStream, probably it's a good idea to avoidStreamExinside theflatMap. Though according to my tests the difference become significant (say, more than 5%) only on very artificial cases.Note that some
StreamExoperations 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()).