hst337
The benchmark
Mix.install [:benchee]
defmodule X do
def dot(map) do
[
map.x + map.y,
map.y + map.x,
map.x + map.y,
map.y + map.x,
map.x + map.y,
map.y + map.x,
]
end
def annotated(%{} = map) do
[
map.x + map.y,
map.y + map.x,
map.x + map.y,
map.y + map.x,
map.x + map.y,
map.y + map.x,
]
end
def match(%{x: x, y: y}) do
[
x + y,
y + x,
x + y,
y + x,
x + y,
y + x,
]
end
defmacrop dot(map, key) do
quote do
:erlang.map_get(unquote(key), unquote(map))
end
end
def safe_dot(map) do
[
dot(map, :x) + dot(map, :y),
dot(map, :y) + dot(map, :x),
dot(map, :x) + dot(map, :y),
dot(map, :y) + dot(map, :x),
dot(map, :x) + dot(map, :y),
dot(map, :y) + dot(map, :x),
]
end
defmacrop match(map, field) do
quote do
%{unquote(field) => value} = unquote(map)
value
end
end
def match_every_time(map) do
[
match(map, :x) + match(map, :y),
match(map, :y) + match(map, :x),
match(map, :x) + match(map, :y),
match(map, :y) + match(map, :x),
match(map, :x) + match(map, :y),
match(map, :y) + match(map, :x),
]
end
end
Benchee.run(%{
"dot" => fn -> X.dot(%{x: 1, y: 1}) end,
"annotated" => fn -> X.annotated(%{x: 1, y: 1}) end,
"erlang.map_get" => fn -> X.safe_dot(%{x: 1, y: 1}) end,
"match" => fn -> X.match(%{x: 1, y: 1}) end,
"match_every_time" => fn -> X.match_every_time(%{x: 1, y: 1}) end,
}, warmup: 1, time: 2)
And the result is:
Name ips average deviation median 99th %
match 7.46 M 133.99 ns ±22658.59% 90 ns 184 ns
match_every_time 7.33 M 136.44 ns ±23751.72% 93 ns 181 ns
annotated 7.22 M 138.59 ns ±23522.99% 92 ns 196 ns
erlang.map_get 6.67 M 149.82 ns ±21303.83% 105 ns 212 ns
dot 4.24 M 235.62 ns ±16830.96% 137 ns 266 ns
Comparison:
match 7.46 M
match_every_time 7.33 M - 1.02x slower +2.45 ns
annotated 7.22 M - 1.03x slower +4.60 ns
erlang.map_get 6.67 M - 1.12x slower +15.83 ns
dot 4.24 M - 1.76x slower +101.63 ns
Explanation
First of all, construction like map.field get’s compiled into this by elixir compiler. This is a feature of Elixir runtime and it is caused by feature of calling functions without (). However, code map.field() gets compiled to the same expression.
case map do
module when is_atom(module) -> apply(module, :field, [])
%{field: value} -> value
_ -> raise BadMapError
end
matchgenerates the fastest core_erlang and beam for this problem. Rule of thumb: pattern matching is always the fastest way to access the data in collections in both Erlang and Elixir.annotatedgenerates almost the same core_erlang asdotversion, but compiler sees that themapvariable in the function body will always be a map (otherwise it wouldn’t pass the matching in args) and it optimizes thecasegenerated bydotto just a pattern matching. So it generates the same BEAM asmatchversionerlang.map_getis a very unpopular way to access the key of a map, and it is the third way to do so, added in one of the latest OTP version. It is actually a separate BIF and it is slower because it performs a map type check on every calldotis the slowest one, because it performs a type check and a jump on every key access
Conclusions
- Annotate your maps to have better performance of
., or at least try to express as much code in pattern matching as possible - Rewrite nested access like
map.submap.subsubmap.fieldinto pattern-matching, or at least use Pathex. - Use Tria optimizing compiler which performs analysis to simplify the
casegenerated by., thus extracting the best performance for the.expression.
Trending in Discussions
There has been a thread to discuss the Stack Overflow Developer Survey on this forum every year since 2018, so here’s yet another one for...
New
Hi there! :wave:
@frigidcode and I (but mostly him) have been running an Elixir Book club, we’re almost done with Designing Elixir Syste...
New
I love Elixir. It’s one of 2 programming languages I’ve ever fallen in love with.
But I don’t use it anymore.
Serverless was the promis...
New
What IDE or editor are you using for Elixir development?
Personally, I use Zed, and I really like it, but sometimes I wish there were a ...
New
Fly’s CEO posted this recently - Turn And Face The Strange · The Fly Blog
It says that Fly is going all-in on sprites, which is a worry ...
New
This was an interesting post by Jose. Curious to hear what others think. Evolving programming languages in the AI era - Dashbit Blog
Gen...
New
Hey guys!
Curiosum team has just published the State of Elixir results on Elixir Hub: see the results here.
1018 participants, 45 quest...
New
Other Trending Topics
I fully migrated to my own harness from Anthropic/Gemini and I think it’s time to share it. Welcome DSH, the DeepSeek Harness, fully writ...
New
Hey. Is there anyone here who creates agents in their apps? Not talking about using agents, but creating them. I’m finding it pretty diff...
New
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
Emily is an Elixir library that runs Nx computations on Apple’s MLX. Install it as the default Nx backend and Nx, defn, Axon, Nx.Serving,...
New
(I just needed to vent somewhere and LinkedIn is full of hope, or hype, I’m not sure which exactly)
AI dream has many faces, but general...
New
In 2021 I started a new library called Tempo with the objective of modelling time as a set of intervals - not as instants. In 2022 I gave...
New
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #ai
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #blog-post
- #elixirconf-us
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #security
- #hex











Showing Posts 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
lud
You are extracting the values only once here.
D4no0
Indeed the 2x performance penalty is just too much, it doesn’t make any sense.
hst337
No, that’s not the reason. The evaluation of extracting the field is pure, so compiler performs optimization in every case (except dot) that extract the data only once. However, some of them perform additional checks upon every call. This is what this benchmark shows.
I’ve updated the benchmark to reflect in-place matching.
cc @D4no0
lud
Interesting, thank you.
The compiler could optimize that as well though. Are you certain it doesn’t ?
I wonder why in my first benchmarck the match head was consistently slower then.
hst337
If you specify functions not in the body of a module, they’re interpreted as
erl_evalstructures. And this is not suitable for benchmarkinglud
Ok but in my second benchmark they were defined with
defin a module.sodapopcan
@hst337 Super interesting, thank you for this.
Does Tria’s
.implementation sacrifice any features of Elixir’s? IE, could Elixir not also make this optimization? Perhaps you’ve talked about this before in the forums and I missed it (I generally follow those threads silently as they are a bit out of my wheelhouse).Overall this doesn’t dissuade me from using
.when I feel it reads better, but I will think now twice in situations where I favour.in a readability coin toss.D4no0
I think this is an anti-pattern, you should use whatever makes the code readable and maintainable and not dwelve into these low-stake optimizations, as they are negligible in the big picture. Hardware becomes more powerful and cheaper by the minute and your time not.
If the optimization was not already implemented in elixir, means that there is some reason for that or it will be implemented in the future.
sodapopcan
I agree 100%, I just meant I will use this knowledge to now favour pattern matching in situations where I could go either way. I don’t generally favour one over the other, it’s always situational. Every once in a while I find myself not caring which I use, so why not use performance as a tie-breaker, no matter how small it may be.
I figured, but I’m still interested to know what it is!
hst337
Nah, it is not going to be implemented in the future, because it is just too much work for Elixir team. I’ve implemented it, but my implementation has insignificant limitations like slightly slower runtime recompilation. My ideas won’t become a part of the language any time soon. Core team of Elixir is interested in static typing, while core team of Erlang is interested in their own customers, who are in this 0.1% of users, who actually use hot-reloading in production
There was no reason in introducing this kind of syntax in the first place. Calls without parentheses could be implemented without this kind of performance drawback, like constructs where the left argument of
.is not a compile-time atom and there are no parentheses or args, could always be treated as:erlang.map_get.So this is a language design issue, and, to be honest, it is not very much of an important issue. I wrote a compiler which is able to overcome it, and simple annotation restores the performance back to 100%. Other languages have UBs, untrackable exceptions and forkbombs in 7 chars, so creators of Elixir did a good job there.
No, Moore’s law stoped working a while ago, and maximum number of cores in one CPU, and maximum number of CPU’s in one motherboard have their limits. We either optimize our code, or hope for the best in terms of quantum computing