Really neat, I’ll give this a go.
dimitarvp
dimitarvp
…And I tried it. Does what it promises. My problem is that the project I am participating in is huge (1100+ Elixir files) and the output isn’t giving me a direct feedback what to address because the transitive dependency chains are like 40+ nodes. 
I used verbose compilation and just touch-ing files and I despaired. 
Wish Elixir had compiler apparatus to tell you which exact statements in the source file lead to compile / runtime dependency between files. 
Some of the files are huge, there are use statements, there are macros, there are Phoenix peculiarities (dependencies between router and views and various utilities) so you can very easily get lost in all this.
Not your fault, of course, the tool is useful! Thank you for it.
0
mpope
This sounds oddly familiar to an issue I experienced on an Erlang project. The project was passing macros to erlc at compiletime with -d, and due to a dependency chain it caused a whole-app recompile for each change. Could something similar be happening with your Elixir project? This escaped xref and other tools completely.
0
schnittchen
I noticed that a simple alias M can make the containing file compile-time depend on the file defining M.
This might be legitimate, but if not, making the compiler not mark the aliased modules’s file a dependency would drastically reduce overall cases.
1
axelson
Scenic Core Team
Have you given DepViz a try?
I spoke about it at Code BEAM BR last year (in english): https://www.codebeambr.com/video/12
That is not quite accurate, an alias will only cause a run-time dependency. However, compile-time dependencies are transitive so if A->compile-time->B and B->run-time->C, then when C changes, A will need to be recompiled.
3
mcampbell
dimitarvp
Just did. It’s super laggy though. I think it could be very useful for smaller projects.
I am still trying to learn these and what does an “export” or “runtime” dependency even mean.
0
riebeekn
Did you have any success in finding a strategy for diagnosing your issue?
I’m in a similar situation, working on a large project with a ton of files. In some cases changing the css class in a template results in hundreds of files being recompiled. Turning on verbose compilation is somewhat helpful but as you say trying to track things down gets overwhelming quickly!
0
dimitarvp
Nope, unfortunately gave up. The company I worked for back then was extremely output-driven so doing R&D was frowned upon unless you achieve results in a day or two which is unrealistic for such a hard and exploratory task. We parted ways soon after.
Since then I haven’t worked with bigger code bases in Elixir – only in Rust. Those I work with in Elixir are small to medium.
I’d love to work on this again one day – there’s a potential to improve things by piping several CLI tools at the tail of mix xref ... – but between my constant fight to undo a potential serious health condition and working part-time, it seems it ain’t happening for now.
0
sodapopcan
I recently dealt with a larger project that had these problems.
This info is scattered around these forums and I know someone wrote a blog post recently but I can’t find it.
Basically the main culprit is pretty much always cyclical dependencies between modules and, depending on how intertwined they’ve gotten, it can be really hard to fix.
Basically look for things like this:
defmodule A do
def a, do: "a"
def b() do
B.b()
end
end
defmodule B do
def b, do: "b"
def a() do
A.a()
end
end
Even if they don’t explicitly cause a compile-time deps (my example won’t), you want to avoid code like that in general. It gets tricky with Elixir since some things were are normally just runtime deps can become compile time deps if the thing they depend on has a compile time dep. For example if I were to introduce the following:
defmodule C do
@b B
def b, do: @b.b()
end
…now both B and A have a compile-time dep on C (with A also depending on B). I won’t get into why this is to keep this post shorter, but avoiding cyclical dependencies will avoid this scenario altogether. (I’m sure someone is going to correct me on me calling them cyclical but I’m not sure what else to call them).
The solution is to always(*) design your module hierarchy as a DAG. Ensure that children never talk to their parents and that when siblings talk it only goes in one direction (and never loops).
(*) of course there are exceptions to every rule
Anyway, sorry if I’m telling you things you already know, but that is where I would look first. People often jump to eliminating the easy targets (like removing references to modules within other module bodies). Those help, but honestly, having a few compile time deps isn’t so bad so long as they are in files that aren’t often changed.
Unfortunately I can’t remember the exact xref commands I would use, but this was a common one:
$ mix xref graph --sink SOME_FILE_THAT_GIVES_YOU_HECK.ex --label compile
…where SOME_FILE_THAT_GIVES_YOU_HECK.ex is a file that causes tons of recompilations. This will show you all the files you have with compile time deps on that file. If you remove the --label compile then you should get an insanely large tree. It’s useless to look at the whole thing but what you want to do is look for repeating files, like so:
a.ex
|-b.ex
|-|-c.ex
|-|-|-d.ex
|-|-|-|-e.ex
|-|-|-|-|-a.ex
This situation can be very hard to detangle, especially if a.ex appears, nested, again.
1