Alias vs import performance

Ok, TIL. My bad

This is correct. Both imported and aliased calls are remote calls.

import and alias do not change if a function call is remote or local…

alias Foo.Bar
Bar.baz()

import Foo.Bar
baz()

Will both result in BEAM bytecode roughly equivalent to the following and therefore be remote calls:

Foo.Bar.baz()

Is that true? I always thought import just did a compile time check for the functions’ existence, but still generated the remote call AST.

That’s a good point, I forget that local vs remote calls have slightly different hot-code-reloading characteristics, and import vs alias determines if they are local or remote.

I’d be curious to see what the performance diff between the two is, even though it’s totally negligible to every application I can conceive of. I did some digging around the core erlang docs and BEAM internals book and there are slightly different instruction sets for them, but I couldn’t divine what the end cost to the caller would be.

At any rate, it’s the lowest level of perf difference possible above the bytecode level, so whichever produces the most maintainable code for one’s situation is to be preferred for sure!

I am not so sure. IIRC imported functions aren’t remotely called, which mean that if you overwrite imported module in the runtime then the module will still use old implementations. alias will make calls remote, so there will be negligible performance hit, but it will provide more flexibility.

Important to emphasize: this only introduces perf penalties during compilation. By default that is only once each time you deploy to production, and every time you change files in a dev environment.

Your original question asks if this affects app performance, which for most app production deployment techniques means only runtime perf, not compile time perf. In this case there is no impact.

Edit: meant to reply to @Kurisu, sorry @LostKobrakai

Thank you for this clarification. ^^

There absolutely is a cost to using import, because it needs to require the selected module as part of its functionality. require does cause a compile time dependency, which means both modules can no longer be compiled in parallel, but need to be compiled one after the other. The upside is that you can check at compile time if certain functions are actually defined in the external module, what you can’t do otherwise. Having a compile time dependency on a module means the current module needs to be recompiled if the module it depends on changes. So for the router helpers it at least means with each route change the compiler will need to at least recompile all the view modules.

After reading this about upgrading to Phoenix 1.4:

A Routes alias has been added to app_web.ex for view and controller blocks in favor over the previously imported AppWeb.Router.Helpers .

The new Routes alias makes it clearer where page_path/page_url and friends exist and removes compile-time dependencies across your web stack.

Should we consider that there is at least a compile-time performance matter between alias and import ?

I found this topic because I was wondering if I will import back the router helpers in my phoenix project as before 1.4 version…