slouchpie
Are module attributes "read" multiple times in same function?
Greetings comrades,
According to: https://elixir-lang.org/getting-started/module-attributes.html#as-constants
Every time an attribute is read inside a function, Elixir takes a snapshot of its current value.
My question is:
In this function:
@money %{amount: 0, currency: :DOGE}
def reset_global_debt do
for human <- Earth.list_humans() do
update_financial_record_for_human(human, %{
"total_amount" => @money.amount,
"base_currency" => @money.currency
})
end
end
do 2 copies of @money get created, since it is “read” twice?
I hope not…
Marked As Solved
eksperimental
Here’s the code.
you can clone it GitHub - eksperimental-help/slouchpie · GitHub
Unoptimized: slouchpie/lib/foo_big.ex at main · eksperimental-help/slouchpie · GitHub
Optimized: slouchpie/lib/foo_small.ex at main · eksperimental-help/slouchpie · GitHub
$ mix compile
$ touch lib/foo_big.ex && rm _build/dev/lib/slouchpie/ebin/Elixir.Foo.Big.beam
$ time mix compile
Compiling 1 file (.ex)
Compiling lib/foo_big.ex (its taking more than 10s)
real 0m33.185s
user 0m28.222s
sys 0m4.836s
$ touch lib/foo_small.ex && rm _build/dev/lib/slouchpie/ebin/Elixir.Foo.Small.beam
$ time mix compile
Compiling 1 file (.ex)
real 0m2.502s
user 0m2.306s
sys 0m0.331s
$ ls -alh _build/dev/lib/slouchpie/ebin/Elixir.Foo.*.beam
23M Dec 15 14:14 _build/dev/lib/slouchpie/ebin/Elixir.Foo.Big.beam
2.1K Dec 15 14:15 _build/dev/lib/slouchpie/ebin/Elixir.Foo.Small.beam
$ elixir --version
Erlang/OTP 24 [erts-12.1.2] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [jit]
Elixir 1.13.0 (compiled with Erlang/OTP 24)
UPDATE:
Here are the benchmarks
https://github.com/eksperimental-help/slouchpie/blob/main/benchmarks/foo.exs
Elixir 1.13.0
Erlang 24.1.2
Benchmark suite executing with the following configuration:
warmup: 2 s
time: 5 s
memory time: 5 s
parallel: 1
inputs: none specified
Estimated total run time: 24 s
Benchmarking Unoptimized: Foo.Big...
Benchmarking Optimized: Foo.Small...
Name ips average deviation median 99th %
Optimized: Foo.Small 292.62 K 3.42 μs ±436.00% 2.46 μs 6.48 μs
Unoptimized: Foo.Big 83.26 K 12.01 μs ±123.18% 7.73 μs 30.17 μs
Comparison:
Optimized: Foo.Small 292.62 K
Unoptimized: Foo.Big 83.26 K - 3.51x slower +8.59 μs
Memory usage statistics:
Name Memory usage
Optimized: Foo.Small 4.53 KB
Unoptimized: Foo.Big 9.09 KB - 2.01x memory usage +4.56 KB
**All measurements for memory usage were the same**
Also Liked
benwilson512
It is as if you hand typed that map in two places. This can affect compile times, but it generally requires very large constants to be an issue.
lud
If you are seeing this because of “decompiled” code, keep in mind that this code is built from the debug_info or abstract_code chunks of the beam files. I am not sure those contain all optimizations done by the compiler.
lud
If you can read erlang you can use mix decompile to turn your compiled module into erlang source. And you will see that whenever an @attribute is used, the litteral value is present in the source.
Now if you cannot read erlang I guess you will recocgnize your own data enough to verify too.
Popular in Questions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #javascript
- #code-sync
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance









