I have a question with parallelisation. let’s say ...

# advent-of-code

[Jakub Gwóźdź]

I have a question with parallelisation.
let’s say that my regular part2 in day 12 (the springs vel “1D nonograms”) looks like this:

fun part2(input: Input) = input.map { calc(it.repeated(5).trimDots()) }.sum()

seems like a candidate to do the mapping concurrently, so no core is slacking, but no matter if I implement it via java8 .parallelStream, or runBlocking/async/awaitAll, my results are actually worse. in the above example from 40ms sequential to ~70ms in parallel.
Is it to be expected on such small work pieces?

I aim to fit all 50 stars under 1 second total, but we’re merely halfway there and I’m already there 🙂

[Tomasz Linkowski]

In my opinion, it's simply the overhead of scheduling the work, including internal synchronization of either Stream's ForkJoinPool or whatever executor Kotlin uses under the hood. For such short-lived pieces of work, it just doesn't seem worthwhile.

[Jakub Gwóźdź]

probably a lot of it comes from suspending world. I saved a lot after refactoring from DeepRecursiveFunction (which is suspending) to normal recursion

[El Anthony]

I tried a parallel solution and it took longer too. I think it's because the problem is very easy to solve, it takes almost no time, and the overhead of starting and synchronizing coroutines should be higher.