The Erlang compiler is quite smart when compiling patterns but there are some things which are extremely difficult to optimise. So it can be really smart with atoms, integers, tuples and lists. However strings, and binaries which is how they are implemented, are much more difficult; in many cases it can’t do better then testing them sequentially which is why you can get some improvement by reordering them. This is a case where lists strings can be more efficient.

So in your example it can group all the clauses and only do the list checking and extracting only once it still needs to test the strings sequentially.

Note that while the pattern matching compiler may choose to reorder clauses and checking it will semantically always behave as if it is done sequentially.

In Erlang function heads and case are pattern match from top down. I expect Elixir would be similar. In general I prefer ordering in the most readable manner, especially for the poor sod (usually me) who has to support the code.

Thinking too much about this is very likely a case of premature optimization: Only if you have an actual implementation that is too slow in a certain regard, and you have benchmarks that measure this, does it make sense to optimize in such a way.

Until you ever reach such a situation, readability is more important than hypothetical speed.

That said, I’m fairly certain (based on earlier papers on the implementations of pattern-matching I read) that Erlang is able to do at least a binary-search if the patterns are restrictive enough. (And patterns/guards that occur in multiple patterns are also probably only executed once). In some limited cases it might even be possible to perform an immediate jump to the correct implementation (such as when all patterns are different consecutive integer values).

In other cases, indeed, the first pattern is matched first, and then we continue on to the next.