Also, though, just avoid calling modules from other module bodies. For example, there was a lot of this in the codebase I worked in:
defmodule Foo do
@foos = %{
a: A,
b: B,
c: C
}
end
Don’t do that!
sodapopcan
riebeekn
riebeekn
axelson
Scenic Core Team
Not quite, you have that reversed. Now C has a compile-dependency on both A and B. The compile-time dep on B is direct, but the compile-time dep on A is transitive (because A depends on B at compile-time). This means that if the a.ex file or b.ex file is changed then c.ex needs to be recompiled (it generally doesn’t make too much difference but compilation dependencies are tracked on a per-file basis even though the dependencies are introduced on a per-module basis).
I’m pretty sure this is the blog post you are referring to:
https://medium.com/multiverse-tech/how-to-speed-up-your-elixir-compile-times-part-2-test-your-understanding-f6ff3de5eb5d
I highly highly recommend it to anyone struggling with recompilation in Elixir. It’s well worth the time to read through and test out the exercises.
Also a shameless plug for anyone that wants to narrow down where they might want to focus their recompilation efforts I wrote a tool called DepViz:
2
sodapopcan
One thing that got used a bunch at my old company was repurposing behaviour modules for other things. For example, a lot of them would expose a function to enumerate all the modules that implemented the behaviour (which is not a good idea when you think about it). Anyway, that was one more thought I had that might possibly be in your codebase.
0
sodapopcan
riebeekn
Was revisiting this a bit today and realized I forgot to mention that in addition to the sugggestions above we found adding GitHub - sasa1977/boundary: Manage and restrain cross-module dependencies in Elixir projects · GitHub to be super helpful. It helped surface some poorly defined boundaries we had going on.
3