Does the compiler optimize contructs with `_` or with `_variable`

Hey @mszmurlo values passed to functions are not copied. Values in Elixir are immutable, so no copying needs to occur when a value is passed to a function.

When you say _ = some_var do you mean a variable of _ = some_function_call(x) ? In the case of _ = some_var or even x = some_var no work happens at all and I believe the whole thing is optimized out. Again values are immutable so the runtime doesn’t have two things to deal with when you do x = some_var it just has one thing.

Not your exact question but the binary efficiency guide has a section which mentions that unused variables in binary matches are optimized out regardless of whether they start with an underscore. I’d imagine this is true in general (that the underscore doesn’t matter), though in practice of course the Elixir compiler will complain either way.

Yes, this sounds very reasonable! Thanks for your enlightenment.

No, I really meant _ = some_var. To give the context of my question, I was building a template compiler based on EEX. I’m creating dynamically functions with the following signature MyApp.Module.SubModule.template_name(assigns) out of template files module/sub_module/template_name.eex. When the template doesn’t use the assigns bindings I got a warning saying that assigns is not used. I spent hours trying different things, playing with the @compile directive but the only way I found to get rid of the warning was to actually use assigns by adding at the end of the template <% _ = assigns %>. I was wondering if it generated any kind of overhead, but obviously, it doesn’t

This introduces no overhead in runtime in practice. Erlang compiler use SSA graph intermediate code representation form where removing such line becomes trivial.

Even if you do

y = x
f(y)

It will be compiled to exactly the same byte and native code as f(x)

It is a great question.

First of all, structures in Elixir are immutable, but not in a sense of immutability like in Rust or const in C. They are never copied on passing as an argument, but they may be copied (or partially copied) on mutation. So no, it won’t be copied.

Second, is that there are some other optimizations which might happen. Consider this code

def example do
  x = {f(), g(), h()}
  my_func(:error, x)
end

If my_func is defined in the same module and inline is enabled, it may get compiled to something like

def example do
  f()
  g()
  h()
  some_thing_else()
end

You can see that operation of constructing the tuple is removed and my_func was inlined.
But if my_func was defined in some other module, it won’t be inlined and code would be compiled without any optimizations.

I wonder if there are situations where it can’t remove the tuple.

There are and in most cases it won’t be removed. Erlang compiler can’t rely on information about functions from other modules (otherwise it would introduce dependency, and current hot module reloading implementation does not support it). Plus, inlining must be explicitly specified with @compile :inline. And there are also limits to compile-time analysis

I’ll just continue to write code in a performant way, tend to be more readable to in Erlang/Elixir if you reduce allocation and lean into recursive functions anyways.