Elixir vs. Erlang benchmarks - is one faster than the other?

There are no differences, both compile to the same byte code. Erlang is not more “raw” or low level than Elixir.

• For comprehensions (for lists) are more efficient in erlang, I think.
• Enum functions are slower than their counterparts in erlang since they do more work (protocol dispatch).
• Functions that are wrappers around erlang’s functions (without @compile {:inline, ...}) require additional function call, which increases reduction count and can affect execution time of that function.

Yes! Elixir is slightly slower because we dispatch to Enum.reduce and Erlang doesn’t perform a remote call.

We inline most common types with the list type coming first. So for the builtin types, that should be no difference in performance.

@compile {:inline, ...} only works within the same module so it is not a general mechanism for wrapping Erlang functions. The Elixir compiler, however, does inline most of its calls to :erlang.

So there are tiny differences in some very specific cases, but they are quite unlikely to matter in general.

Also elixir code might be sometimes less efficient because of the way people write it and not due to the language itself.

• using string concatenation instead of iolists
• using structs instead of records
• accessing map elements via . several times instead of a single pattern match
• using Keyword.fetch on every element in an “opts” list instead of iterating over it once
• in general, trying to use elixir “imperatively” thus producing subpar code (many examples of this on this very forum)

In general the differences are tiny. Those should also decrease in the next OTP release with several patches to the compiler optimising some idioms common in Elixir.

There are also some cases, where the way Elixir programs are usually structured might be more efficient than Erlang programs.

• accessing map elements via . instead of maps:get calls
• using binaries for default string type instead of charlists
• doing some computation at compile-time via macros

And there are probably more - it’s not black and white. Overall I wouldn’t expect major performance differences between Erlang and Elixir code, especially if you’re writing it paying attention to performance.

I made a fixed version a half-year ago! ^.^

Mine is actually faster than even erlang’s in some cases (same speed in the average case) due to my design requiring you to essentially ‘type’ the arguments so it can generate the most efficient code. It was mostly a proof of concept though (hence why it’s in my ‘proof-of-concept’ repo) and never finished it up to put it out into it’s own package.

But the syntax (as from this benchmark ex_core/bench/comprehension_bench.exs at master · OvermindDL1/ex_core · GitHub ):

defmodule Helpers do
  use ExCore.Comprehension

  # map * 2

  def elixir_0(l) do
    for\
      x <- l,
      do: x * 2
  end

  def ex_core_0(l) do
    comp do
      x <- list l
      x * 2
    end
  end

  # Into map value to value*2 after adding 1

  def elixir_1(l) do
    for\
      x <- l,
      y = x + 1,
      into: %{},
      do: {x, y * 2}
  end

  def ex_core_1(l) do
    comp do
      x <- list l
      y = x + 1
      {x, y * 2} -> %{}
    end
  end
end

I’m actually surprised at that it inlines at the compiler step instead of just making those calls defmacro delegations or so… Seems a duplication of effort? (Though I’m betting the compiler-level inlining was added well before macros were. ^.^)

Even the Elixir standard to_string/1 can take an iolist and put out a binary just fine so there is no reason to. In some cases binary appending is more efficient however.

This speed difference should be reduced in OTP 21 I think it was, though there will still be a difference, just not ‘as’ big.

It would be interesting Elixir didn’t use . for maps and instead had a built-in lens/prism functionality that ended up generating matchers.

Yeah the default access pattern of opts[:blah] is definitely not the most efficient by far… (and yet I do it a lot due to its simplicity) ^.^;

Back in my ol’ Erlang days I had a fairly simple library, similar to the commandline-opt-parse module in Erlang that did a single pass over the output and spit back out a tuple (based on the requested values) after fixing them up (erlang style proplists are so much nicer than elixir style keyword lists) into a normalized output based on what I wanted, or else either log an error or perhaps throw an error, etc… I really should rewrite it to handle Elixir’s more limited KWLists sometime, smaller implementation for sure.

+++

Doesn’t . delegate to maps:get or is it going to some internal implementation to match out (which shouldn’t that then be the same speed as maps:get unless it were inlined into the module?)?

Ooo is the new OTP version going to make iterating over binaries faster than lists? Lists have always been so much faster than binaries for so many things ever since I started erlang (though significantly larger).

This this this is a big thing. Erlang had it’s share of macro-like things but they are a bit of hell to write, especially compared to Elixir macro’s.

+1 They still generate the same code to the same VM. ^.^

Tell me more. I’m new to Elixir and all of the learning materials I’m using focus on structs. Didn’t realize Records were a thing until today. What are the pros/cons and why is there a performance benefit to Records over Structs/Maps?

See

I think they are implemented slightly differently in elixir, though.

But structs are generally much nicer to work with because they are maps and not tuples. For example, IIRC cowboy 2.0 moved from using records to represent its Req object to maps. But from reading its (as well as ranch and cowlib) source code I got a feeling that cowboy was striving for completeness and ease of use rather than performance.

foo.bar expands to:

case foo do
  %{bar: bar} -> bar
  %{} -> :erlang.raise({:badkey, :bar, foo})
  _ -> apply(foo, :bar, [])
end

I was mostly writing about memory size, which has some less direct effect on the applications triggering less GC, sending binaries between processes without copying, allowing for more structural sharing with sub binaries, etc. The difference is actually not that big on OTP 20 already when iterating over bytes (I think there are some things that should make binaries even faster on OTP 21).

Operating System: macOS
CPU Information: Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz
Number of Available Cores: 8
Available memory: 16 GB
Elixir 1.7.0-dev
Erlang 20.3
Benchmark suite executing with the following configuration:
warmup: 2 s
time: 5 s
parallel: 1
inputs: none specified
Estimated total run time: 21 s

Name                  ips        average  deviation         median         99th %
list             265.45 K        3.77 μs    ±19.34%        3.60 μs        6.90 μs
binary_byte      210.06 K        4.76 μs    ±25.28%        4.40 μs        8.60 μs
binary_utf8       93.43 K       10.70 μs    ±30.39%          10 μs          20 μs

Comparison:
list             265.45 K
binary_byte      210.06 K - 1.26x slower
binary_utf8       93.43 K - 2.84x slower

Benchmark code: string_bench.exs · GitHub

The Google Groups thread seems to imply that structs/maps will be more performant when doing the typical pattern match and have benefits wrt polymorphism and protocol support. It seems the only thing Records excel at are access within tight loops.

If I understand this correctly, it seems that Structs would outperform Records for the vast majority of general state holding problems. Like the state of a Cowboy Req object and nearly every GenServer.

Am I misreading this?