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!