Both are slow as you can just use math instead of any loop/stream.

Nop.
I just run a benchmark to be sure, with smallNumber = 25 and bigNumber = Integer.MAX_SIZE.

Here are the results :

Benchmark Mode Cnt Score Error Units
MultiplesOf3And5Test.withForLoopAndBigNumber avgt 5 2.680 ± 0.055 s/op
MultiplesOf3And5Test.withForLoopAndSmallNumber avgt 5 28.495 ± 4.046 ns/op
MultiplesOf3And5Test.withParallelStreamAndBigNumber avgt 5 1.044 ± 0.184 s/op
MultiplesOf3And5Test.withParallelStreamAndSmallNumber avgt 5 11284.553 ± 1710.007 ns/op
MultiplesOf3And5Test.withStreamAndBigNumber avgt 5 3.013 ± 0.049 s/op
MultiplesOf3And5Test.withStreamAndSmallNumber avgt 5 94.385 ± 3.109 ns/op

(Yes I used warmup steps to remove JIT and CPU bias)

Here are my interpretations :

• The withForLoop and the withStream are very close with small numbers. The difference comes from the stream initialisation.
• The performance converge with BigNumber
• The parallel implem with default thread-pool stream is 2 time better than every other
• The parallel implem with custom thread-pool could be even better
• People should stop throwing performance asumptions without proper benchmark

Lambdas are not slow. This solution is O(n^2) due to string concatenations (not O(n log n) as another user said), but n is constrained to a very small constant, so the solution is fine. If n was unbounded, the best way to improve this solution would be to use a StringBuilder to concatenate the strings. This would result in a total time of O(n log n) (the time to sort), which is very good.

What if it run in .parallel()?

I don't think it's slow because it's lambda. Correct me if I'm wrong, but it will replace the string every comparison. That's O(n log n) replaces, instead of the usual n.

You are right, though its always intresting to insert a new solution! This gave you a chance to cricically compare and its learning for all of us. Thanks!

This example doesn't include the maximum of the Integer Range.
The better solution will be the BigInteger usage.

For more bigger numbers IntStream is much slower then simple loop.

not really, i have almost similar benchmarks

Using the Comparator here cause the perfomance gap. This code is 3-4x times slower then loops.

It looks minimal and nice since it is Java 8 but i have a little concern about it.

Well, first it is bad in perfomance part. On my PC it is about ~3800000 nanoseconds to run this. The reason why is simple: lambdas.
Also minor, but not last is the variable naming. IMHO, strs, f, st is not readable.

Less iteration, more perfomance.

Basically it is the most perfomance example: on my pc it is about ~500000 nano seconds which is best solution out there.

Nice!