I was wondering if the compiler makes any optimization for constructs like below.
# Let’s define `my_func`
def my_func(:ok, param) do some_thing_with(param) end
def my_func(:error, _param) do some_thing_else() end
# and then call my_func
my_func(:error, some_var)
Does the compiler copy the value of some_var but then simply doesn’t use it or does it not even bother to copy it ?
Same question if I write _ = some_var. Does the compiler simply discard the line as it does nothing or does it do something that uses CPU ?
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 useassigns 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.
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.
