I’m very proud to announce Fixefid 1.0.0 has been released!
Fixefid is a Java library for working with flat fixed formatted text files.
Fixefid 1.0.0 has been released!
I’m very proud to announce Fixefid 1.0.0 has been released!
Fixefid is a Java library for working with flat fixed formatted text files.
Is it always convenient to use parallel streams?
Java 8 has introduced with the Stream the possibility of using in a very simple way all the resources made available by the hardware, in particular the cores of the multicore architectures. And all this with the paradigm of declarative and non-imperative programming.
For example, suppose you have to do a batch that looks for a string in all the files that have a certain prefix in a certain directory. The batch must notify in a log in which files the string is found.
It is interesting to compare the two approaches, pre java 8 and java 8 with the streams.
I used my dev computer, a Samsung laptop with this features:
Having 4 Threads I expect the performance of the parallel stream solution to be 400% better than the classic pre java 8 version.
The code that uses the pre java style 8 is as follows: StringMatchingOld
The code that uses the streams is as follows: StringMatching
The code that uses the parallel streams is as follows: ParallelStringMatching
These are the results (4 files read):
What is going on? Truly strange, there is no benefit in the use of the stream (I think also from the point of view of the code… I don’t think it’s more readable but this is another story… I’m getting older…). Furthermore, we see that using parallel streams does nothing but make things worse.
It seems that reading the files does not find any improvement in the use of the streams. However, the fact remains that declarative programming makes it possible to abstract from current hardware, so maybe on a server with better hardware than my development pc, parallel streams performance is better.
Or maybe I’m doing something wrong … I’m looking forward to that.