I was looking today at slow compile times in my app, and I concluded, that it is because of defdelegates and imports

Instead of editing the app, I started wondering if those two macros must be compile-time dependencies.

In a generic defmacro case, we create a compile-time dependency.

In a case like A -> (compile) -> B -> (runtime) -> C,
if C changes, we need to recompile A.
This recompilation happens because changing C may change return values of B, and A might use them during its compilation.

That means all changes of runtime dependencies of B trigger recompilation of A, and that is unavoidable in a general case.

I believe it is not the case with defdelegate. We know how the macro works, and that it doesn’t care about the return value. It cares about the function name, arity, and its docs, so we could potentially avoid recompiling delegating module.

So in case like A -> (defdelegate) -> B -> (runtime) -> C,
if C changes, we don’t have to recompile A. We need to recompile A only if B changes.

I believe imports behave similarly. Importing module doesn’t care about return values of imported functions, so it could potentially skip the compilation if runtime dependencies of importing module change.

So in case like A -> (import) -> B -> (runtime) -> C,
if C changes we could potentially skip compilation of C.

For the curious people out there, I’d like to present why those two little macros cause quite a lot of recompilation.

We use Phoenix contexts, and very often the structure ends up like this:

context.ex (a bunch of defdelegates to use_case modules)
context
| - use_case1.ex (some defdelegates to helpers)
| - use_case1
|   `- use_case1_helper.ex
` - use_case2.ex 
...

One of the contexts is central to the app, and almost all other contexts use it. In the web layer view_helper.ex calls context.ex to calculate some info for displaying some entities. Different views import some functions from view_helper.ex because specifying the entire module name in templates <%= ViewHelper.function(...) %> seems strange.

In the end, changing use_case1_helper.ex triggers recompilation of context.ex which triggers recompilation of almost all views. In my relatively small app, it is 49 files.

I understand I could change imports to aliases, but maybe changing how the imports and defdelegates work could benefit the broader community.

Was there a discussion about it somewhere? I know that Phoenix.Router changed imports to aliases to solve a similar issue, so there might be something hard I am missing here.

On the other hand, in Elixir 1.6, structs stopped being a compile-time dependency and trigger recompilation only when the struct changes. Would it be possible to apply a similar trick to imports and defdelegates?