Another reason for slow compilation is if given module depends on other slow modules. [1] Is a great resource for understanding compilation. In general, you want to avoid compile-time dependencies between modules as much as possible.

On our Phoenix app, switching from import MyApp.Router.Helpers to alias MyApp.Router.Helpers, as: Routes speed up compilation and limited re-compilations greatly, see: [2]

Elixir 1.6 will ship with improvements to mix xref which should make it easier to investigate this stuff.

[1] http://milhouseonsoftware.com/2016/08/11/understanding-elixir-recompilation/
[2] https://github.com/phoenixframework/phoenix/issues/2530
[3] https://github.com/elixir-lang/elixir/blob/master/CHANGELOG.md#mix-xref

A possible partial fix

instead of using multiple function heads

def fun(a, :foo = b), do: :alpha 
def fun(a, :bar = b), do: :beta

you can help the compiler by making it one function head with embedded case statement:

def fun (a, b) do
  case b do
   :foo -> :alpha 
   :bar -> :beta
end

Routex was not able to build helper functions for 400 (generated) routes causing “too complex” issues during compilation due to the amount of generated function heads. In the upcoming version 1.2 those are rewritten to case statement variants and it now handles more than 2.000 routes.

Yes. I do not expect this for manually written code. If you write 400 function heads yourself, you might be the limit yourself

Fully agree with your advice

Hm, we may have something here
Running mix xref graph --source on those slow modules usually shows the router as a compile time dependency, which in turn depends on lots of controllers, which depend on models, etc.

I am going to try aliasing the router module instead of importing it and check the result.
Thank you @wojtekmach

I would say this is a great optimisation if you are generating the code with metaprogramming.

Otherwise I would almost always recommend to take the most readable approach. There was a similar discussion on similar topics such as how map.key is very inefficient compared to pattern-matching.

This is a implementation detail that can be changed anytime in the future and should not be a concern of the end-user that is the developer.