Reducing incremental compilation times in Phoenix/Ash project

Ash Forum Ash Questions / Help
, ,
1

So I’m building a couple of projects with Elixir/Ash/Phoenix/Inertia/React and I’m being EXTREMELY productive with this stack — I mean it, VERY productive — making great progress on both projects at the same time.

Although, I’ve run into a roadblock that’s been discouraging me and I fear it will get worse. One of the projects has started to grow, and every little change I make in a file is taking quite a while to recompile (incremental compilation). It’s slowing down my productivity a lot. It started at 2–3s and now it’s up to 8–10s on every change.

I’m almost certain this is due to my lack of experience in the language and that I might be doing something wrong with the way I’m architecting/writing my code. I’ve done some research and it seems related to compile/runtime dependencies and the like. I’d really appreciate actionable advice or links to resources that can help me fix this. Will this keep getting worse as my project grows, or can it be kept low?

As a side note, I had Claude analyze my repo and it found 13 circular dependency cycles. I’m sure some of you will resonate with this and can guide me on identifying, measuring, and fixing the problem — and avoiding it in the future.

Thanks in advance.

2

I can’t help you with the Ash side of things, but you can use this tool to get a more concrete view of your dependency graph if that a concern:

3 Likes
3

You can use xref to help better understand how your modules are connected. There can be a bit of a learning curve but some useful commands are:

mix xref graph --format cycles --label compile-connected

and

mix xref graph --label cycles --sink lib/path/to/file/that/causes/many/recompilations.ex

Cycles aren’t 100% avoidable. For example in has_many and belongs_to relationships, A is going to refer to B and B is going to refer to A. But you should avoid calling functions in this scenario, ie, avoid this:

defmodule A do
  def a, do: B.b()
end

defmodule B do
  def b, do: A.a()
end

This is a bit of a deep topic and there are a lot of threads about this on this forum (search for “transitive dependencies”) as well as some blog posts. Here’s a good one. But it’s very hard to give specific actionable advice without seeing some code (though it would require seeing a lot of code which is of course probably not possible and not something I’d really wanna do, lol).

Some brief tips, though:

  • Avoid defining macros in files that change often.
  • Avoid having modules that you sometimes use in some modules, and sometimes just call random functions (or import) in other modules. Split those up.
  • Avoid calling functions in a module’s body. For example, if you have @foo Foo.bar(), change that to def foo, do: Foo.bar(). This can be ok, but these are brief tips so it’s easier to say Just Don’t Do It.
  • Sometimes you want to avoid even referring to a module in another module’s body (though I believe this isn’t as much of a problem anymore)
  • Along the lines of avoiding cycles: don’t (ever) call any Web functions from your domain modules/resources modules.

That’s all I got. If you have more questions I’m happy to try and answer. I’m not a huge expert here though have helped squash compiletime deps in a few projects and enjoy the topic.

4 Likes
4

Wanted to clarify this as it’s not a realistic example—it’s an endless loop that would just crash your program.

The point is is that you don’t even want two modules referring to each other, so don’t even do this:

defmodule A do
  def one do
    B.one()
  end

  def two do
    "Oh hi"
  end
end

defmodule B do
  def one do
    "Oh hi"
  end

  def two do
    A.two()
  end
end

These can be particularly nasty to figure out especially if have a longer chain (which is what it sounds like you have), ie, A calls B which calls C which calls D which calls A again. Usually these chains can be quite long.

Once you manage to get things sorted out, take a look at the Boundary library.

5

Early abstraction is the root of all evil. Micro-services is a classic example, slow compilation due to module dependency is another. And they are in-fact the same problem.

1 Like
6

mix xref graph --format cycles --label compile-connected --fail-above 0 in CI is plenty. All other cyclic dependencies are fine and and don’t affect compile times.

2 Likes
7

Sure, but it sets poor precedent. I think it’s better to keep designs as DAGish as possible.

In fact I was burned by this recently where at the beginning of the project I intentionally introduced a cycle for convenience. As things evolved, it grew in a real problem where everything started recompiling. It was an easy fix (though tedious) but still.

8

Sorry, I got oddly defensive there. Yes, in relation to OP’s question just fixing the problematic ones are all they need to care about. I was talking more from a clean state point of view.

1 Like
9

Thank you everyone for your contributions! My mistake was writing inline action hooks within my Ash resources. Moving them into their own modules fixed the issue. I was even experiencing slow compilation times when changing code in my Phoenix controllers, because they referenced Ash domains, which in turn pointed to resources that referenced other modules in the inline hook implementations—creating the so-called transitive dependencies. Breaking those action hooks into separate modules completely solved the problem. Also worth mentioning @zachdaniel for his support in the Ash Discord community. Thanks again!

3 Likes