Yup I understand now.
At compile-time, every module attribute usage is effectively “written out” in full in the code.
So it’s only a concern for very large constants, or if the attribute is accessed in a compile-time loop (e.g. in macros).
Thanks.
slouchpie
2
eksperimental
A good analogy is what happens when you create a guard with defguard, under the hood it creates two versions of the Macro. one that is executed when is called into the guard context, so it is really limited what you can do there, So no variable assignments is allowed,
so if you want to call two different functions on the same argument, you make two copies of it (similar to what you do in your initial example),
but if the macro is called out of the guard context, is it optimized, so each argument is assigned to a variable, and then it is referred to it, as in my version of your code.
0
slouchpie
For posterity, doing this isn’t better or worse. It’s exactly the same.
Doing money = @money is better, but only slightly. It might save 0.01 nanoseconds of compile time on a 1980s relic.
0
eksperimental
actually if you want to be performant, ( I initially wrote it like this, i just didn’t want to overcomplicate the example)
money = @money.amount
amount = money.amount
currency = money.currency
The benefits are at runtime (you say two Map.get/3 calls for every element in humans), not compile time.
While at compile time a map of two elements is not going to make a difference, make it a map of 1 million entries, you may see the difference.
EDIT: proper way would be
%{amount: amount, currency: currency} = @money
1
slouchpie
Are you 100% certain will be a difference at runtime between:
%{amount: @money.amount}
and
amount = @money.amount
%{amount: amount}
?
0
eksperimental
I don’t understand your example.
The difference at run time is that you save to access the element (you save two calls per loop).
Why would you want to access the element every time in the loop, when you already know it is amount and it is not going to change?
Store it in the variable, and assign it to your new map key.
1
slouchpie
The compiler should change @money.amount to a constant. So it wouldn’t be a map “access”.
0
eksperimental
it doesn’t.
here’s your expanded code.
def reset_global_debt() do
for human <- Earth.list_humans() do
update_financial_record_for_human(human, %{
"total_amount" => %{amount: 0, currency: :DOGE}.amount,
"base_currency" => %{amount: 0, currency: :DOGE}.currency
})
end
end
And if @money would have 1million entries, you will be creating two copies of a map of one million entries, that are going to be stored in your .beam file,
1
eksperimental
you can achieve this by evaluating the call at compile time, by doing:
unquote(@money.amount)
you can do it by calling unquoteonly since you are inside a macro (for)
0
slouchpie
Thanks for the good info.
I’m super surprised that the compiler doesn’t change %{a: 1}.a} to 1.
0