It looks like this github issue Jose opened a month ago may be related: Undesired(?) slow down in ssa_opt_alias · Issue #7432 · erlang/otp · GitHub
It’s the only mention of ssa_opt_alias I can find on Google
pejrich
christhekeele
EDIT: debunked, NVM. See post below
Incorrect Hypothesis
IIRC, multi-clause same-arity function heads compile down to a single function that wraps an equivalent case statement in the Erlang Abstract Format.
Based on my reading of this thread, perhaps what’s taking so long is the compiler doing function-call-reachability checks for every function head. Maybe you could meta-program a single function clause with a single case statement instead, to skip this overhead?
defmodule Test do
@all [{"foo", :bar}, {"fizz", :buzz}]
all_case_statements = Enum.flat_map(@all, fn {k, v} ->
quote do
<<unquote(k), rest::binary>> -> replace(rest, [unquote(Macro.escape(v)) | var!(acc)])
end
end)
def replace("", acc) do
acc
end
def replace(thing, acc) do
case thing, do: unquote(all_case_statements)
end
end
This works for me locally:
Test.replace("foofizzfoo", [])
#=> [:bar, :buzz, :bar]
2
rvirding
Creator of Erlang
That shouldn’t make any difference as the compiler does the same optimisations for the case clauses as it does for the function clauses.
3
christhekeele
That’s what I’m counting on. My (untested, speculative) hypothesis is that the issue (particularly slow compile times for a ridiculous number of function heads) is partially caused by a performance regression during lexical analysis of definitions and call sites; which a single head/case statement avoids despite getting compiled with the same runtime optimizations.
Had to step away from my computer for the day before I could reproduce a setup to see if this helps, but wanted to share the hypothesis before I did. Again, total speculation, but not concerning the optimization pass.
1
christhekeele
I was itching to test this hypothesis, and it looks like it is indeed bunk! Both versions take the same time to compile, based on real rough benchmarking.
This is with 10,000 function heads (22^3 ~= 10k) on my M2 machine:
defmodule Test do
## BASELINE: run without uncommenting any code
## time mix compile --force -> 0.63 secs
@all (for x <- 0..22, y <- 0..22, z <- 0..22 do
{{x, y, z}, Integer.to_string(x) <> Integer.to_string(y) <> Integer.to_string(z)}
end)
def replace("", acc) do
acc
end
## TEST 1: uncomment this block
## time mix compile --force -> 44.51 secs
# Enum.each(@all, fn {{x, y, z}, v} ->
# def replace(<<unquote(x), unquote(y), unquote(z), rest::binary>>, acc) do
# replace(rest, [unquote(Macro.escape(v)) | acc])
# end
# end)
## TEST 2: uncomment this block
## time mix compile --force -> 44.41 secs
# all_case_statements =
# Enum.flat_map(@all, fn {{x, y, z}, v} ->
# quote do
# <<unquote(x), unquote(y), unquote(z), rest::binary>> ->
# replace(rest, [unquote(Macro.escape(v)) | var!(acc)])
# end
# end)
# def replace(thing, acc) do
# case thing, do: unquote(all_case_statements)
# end
end
Interestingly, I didn’t realize I was running OTP 25 at first—so I initially tested this with 100,000 function heads instead (47^3 ~= 100k), and my tests took 60s. Upgrading to OTP 26, however, they refused to finish within 15 minutes, so 
… If you want a distilled example for a bug report, you can use my code here.
2
pejrich
Thanks for doing this! It does at least confirm that my experience isn’t something that’s only affecting me.
0
jakemorrison
It’s a reasonable approach. Sounds like some issue with OTP 26.
I am doing something similar here: GitHub - cogini/public_suffix_list: Elixir library which uses the https://publicsuffix.org/ list to parse DNS domains · GitHub
That’s over 10k heads, and compilation performance has never been that bad.
1
josevalim
Creator of Elixir
Most likely the same as this one: Undesired(?) slow down in ssa_opt_alias · Issue #7432 · erlang/otp · GitHub - TL;DR: they are working on a fix.
This may also help in future cases: How to debug Elixir/Erlang compiler performance - Dashbit Blog
5
pejrich
@josevalim I’m a little unclear on what was added in OTP26 that had such a drastic effect, and what is the benefit of having it there? If it’s for optimization of potentially unreachable function heads, would it be possible for some sort of compiler annotation to skip the new check for these lengthy modules?
If you have a file that is literally this, or something that essentially amounts to this:
File.read!("many_10s_1000s_of_lines.json")
|> some_parsing()
|> Enum.each(fn {k,v} ->
def some_function(<<unquote(k), rest::binary>>, acc), do: some_function(rest, [unquote(v) | acc])
end)
would some sort of @compile {:way_too_many_lines, :dont_even_bother}(obviously don’t rely on me for good naming suggestions 
) help to alleviate this issue, or maybe I’m misunderstanding what the new code is doing, and maybe it’s equally as useful for these types of files.
But just in case you do want more great naming suggestings, this could work:
@compile {:i_know_more_than_the_compiler, ignoring: :ample_evidence_to_the_contrary}
0
josevalim
Creator of Elixir
The linked GitHub issue discusses the optimization and possible fixes already. It is about liveness analysis of variables, which can be used for several things, such as performing destructive updates, decreasing ref counters, etc.
1