Are there performance differences or style preferences in case vs function heads?

1. replacing a case which spans the whole function, wouldn’t make any difference, its compiled to the same bytecode anyway.

def f({:ok, :bar}), do: :baz
def f({:error, _}), do: :bing 

defp f(x) do
  case x do
    {:ok, :bar} -> :baz
    {:error, _} -> :bing 
  end
end

Are therefore equivalent.

2. If you replace a case in a function by a call to a function in the same module, there might be the slight overhead of a local function call, but depending on the optimisation settings, it might get inlined. In performance critical parts I wouldn’t rely on the inline, but in general I do consider foo = find_the_answer(data) much more readable than foo = case data do … end, so I’d prefer extracting into a function most of the time.

3. If you have a case in a function as before and replace it with a function in a different module, you’ll pay the “cost” of a remote call. It will never get inlined. But even here I’d prefer the function call, if it makes sense in the context of the application design.

Conclusion:
Only ever consider the “faster” way when you know its actually a problem. You know what Dijkstra said about premature optimisation?

In general I would favor function heads because of the way Erlang VM treats functions. It’s not about speed. The VM uses function executions, aka reductions, as a means of determining when to allow a process to run. In addition SASL works on functions, having the built-in error reporting work for you is always a Good Thing. Lastly, you can turn on function tracing at runtime, something unavailable with expressions.

Coding wise, I do find it easier on the eyes with another function head then another case block. This also avoids the case lead Pyramid of Doom.

I’m not certain if Elixir case, if, cond are converted internally into function heads or dealt with in a different manner.

In fact, they are not, but it is the other way round. During compilation function heads are compiled into the bytecode equivalent of a case-expression.

I personally have a strong preference for case, because I don’t like the repetition of function name.