Is Scala functional programming slower than traditional coding?

Question

In one of my first attempts to create functional code, I ran into a performance issue.

I started with a common task - multiply the elements of two arrays and sum up

Answer 1

This is a microbenchmark, and it depends on how the compiler optimizes you code. You have 3 loops composed here,

zip . map . fold

Now, I'm fairly sure the Scala compiler cannot fuse those three loops into a single loop, and the underlying data type is strict, so each (.) corresponds to an intermediate array being created. The imperative/mutable solution would reuse the buffer each time, avoiding copies.

Now, an understanding of what composing those three functions means is key to understanding performance in a functional programming language -- and indeed, in Haskell, those three loops will be optimized into a single loop that reuses an underlying buffer -- but Scala cannot do that.

There are benefits to sticking to the combinator approach, however -- by distinguishing those three functions, it will be easier to parallelize the code (replace map with parMap etc). In fact, given the right array type, (such as a parallel array) a sufficiently smart compiler will be able to automatically parallelize your code, yielding more performance wins.

So, in summary:

• naive translations may have unexpected copies and inefficiences
• clever FP compilers remove this overhead (but Scala can't yet)
• sticking to the high level approach pays off if you want to retarget your code, e.g. to parallelize it