Optimize Enum.map/2 for lists

[michalmuskala]

When writing an article about lists I ventured into implementing couple of the core list functions myself. I was surprised when I discovered that the current implementation of Enum.map/2 is not optimal.

I came up with 3 options:

• using for comprehensions (currently used)
• using explicit recursion with accumulator
• using simple consing

The third option seems to be the fastest. That's also the one that is used by :lists.map/2

Tested implementations:

  def map_cons([head | tail], fun), do: [fun.(head) | map_cons(tail, fun)]
  def map_cons([], _fun), do: []

  def map_recurse(list, fun, acc \\ [])
  def map_recurse([head | tail], fun, acc), do: map_recurse(tail, fun, [fun.(head) | acc])
  def map_recurse([], _fun, acc), do: :lists.reverse(acc)

  def map_for(list, fun), do: for i <- list, do: fun.(i)

Results:

cons 100            500000   3.25 µs/op
recurse 100         500000   3.27 µs/op
for 100             500000   4.76 µs/op
cons 1000            50000   30.57 µs/op
recurse 1000         50000   32.59 µs/op
for 1000             50000   43.51 µs/op
cons 10000            5000   308.71 µs/op
recurse 10000         5000   339.36 µs/op
for 10000             5000   449.46 µs/op
cons 100000            500   3135.30 µs/op
recurse 100000         500   4178.06 µs/op
for 100000             500   5025.42 µs/op

Full testing code

Performance gain is steadily around 30%. The difference is not huge (and probably less significant if you do any work inside the mapping function), but given how often Enum.map/2 is used, I think this warrants the change.

[josevalim]

Just to be double sure, please run every benchmark in a separated process.
:)

José Valim
www.plataformatec.com.br
Skype: jv.ptec
Founder and Director of R&D

[michalmuskala]

I must admit I went a lazy path this time - the new testing code

Results:

cons 100            500000   5.62 µs/op
recurse 100         500000   6.47 µs/op
for 100             200000   8.75 µs/op
cons 1000            50000   57.47 µs/op
recurse 1000         50000   59.15 µs/op
for 1000             50000   70.73 µs/op
cons 10000            5000   535.17 µs/op
recurse 10000         5000   573.46 µs/op
for 10000             5000   678.71 µs/op
cons 100000            200   7505.32 µs/op
recurse 100000         200   7814.68 µs/op
for 100000             200   9194.78 µs/op

[josevalim]

Yes. comprehensions have been rewritten to always use Enum.reduce, that's why it became slower. If you find any other use of comprehensions in Enum, we should change it. Can you please send PRs for any other cases you see? Thank you! :)

[splattael]

Just to be double sure, please run every benchmark in a separated process.

@josevalim Interesting, could you explain why? Should we always run benchmarks in separated processes?

[michalmuskala]

I think the concern was to eliminate the effects of garbage collection. Each process has a new heap, so garbage collection will happen at the same time. When you run all in the same process it's not as predictable, as you can accumulate garbage from previous runs.

[splattael]

@michalmuskala That makes sense. Thank you for the explanation :)
benchp is pretty handy! Maybe it should be added to Benchfella :D

[ericmj]

I'm usually a proponent of body-recursive functions but in the stdlib we should strive for highest performance. @michalmuskala did you also measure the tail-recursive version that reverses the list at the end. Tail-recursive should be ~30% faster on x86 according to erlang's efficiency guide.

[michalmuskala]

@ericmj I believe tail-recursive is the implementation I called recurse. It's performance is similar to the body-recursive solution I called cons that I ended up using, because it came out as slightly faster.
I may be wrong on that. Maybe someone could run those tests on other machine that mine.

I've read that part of efficiency guide too - if my benchmarking was correct it seems both solutions are equally performant currently.

[lexmag]

I think using :lists.map/2 makes it even better: comparable performance and obviously less code.

[josevalim]

In my previous benchmarks, tail-recursive is faster for long collections, body-recursive for shorter ones. :lists.map is also great because we inline its code. They are all great solutions.