And this is a great space for optimization my compiler is targeting.
Optimizing for, Enum pipes, plaining nested case-s and removing x.y runtime should give around 20% performance increase for Elixir code
hst337
0
bjorng
Erlang Core Team
Your are right. The Erlang compiler does not do this optimization. It does attempt to keep the stack frame as small as possible when recursing, trimming the stack frame when possible.
Nope, no new tricks for body recursion.
5
josevalim
Creator of Elixir
Enum pipes is hard to optimize without changing semantics.
We can optimize for though. The only way I know how to optimize it though requires doubling its body in the source code based on the generators. Unless we emit some sort of special Kernel.Utils.for for the cases for works on a single collection?
Plaining nested cases is interesting and perhaps even a feature the Erlang/OTP team could be interested in?
And I am definitely curious about the x.y stuff. 
Looking forward to learn more!
0
hst337
Yes, it is hard, but it is not impossible. Right now, I know that these optimizations are possible:
- Convert
sum,count,product,frequenciestoEnum.reduce - Join
zipandreducetozip_reduce - When one of steps is pure, I can join
filterandfilter,filterandmap,mapandmap,mapandreduce,filterandreduce,flat_mapandflat_map,flat_mapandreduce,filterandeach,mapandeach - Optimize
forto plainmap. In my compiler this optimization looks like this:
def join_consecutive([{:lists, :reverse, []} = reverse, {Enum, :reduce, [[], reducer]} = reduce | tail]) do
case reducer do
tri(fn x, acc -> [body | acc] end) ->
[{Enum, :map, [tri(fn x -> func end)]} | join_consecutive(tail)]
_ ->
[reverse, join_consecutive([reduce | tail])]
end
end
filterandempty?can be joined- If I know that
Enum.reduceis definitely called upon a list, I can replace call with:lists.foldl, which will reduce 1 call, but more importantly, will be efficiently inlined by Erlang compiler Enum.into(%{})with fn ormaptoMap.new
Yeah, but this is a hardest optimization I am working on. Benchmarks show that there is almost no general rule where this optimization would increase performance. So, this is only for code size reduction, and must use some profiles, for which I need an infrastructure
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 mapdot(%{} = 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
end
Benchee.run(%{
"dot" => fn -> X.dot(%{x: 1, y: 1}) end,
"mapdot" => fn -> X.mapdot(%{x: 1, y: 1}) end,
"match" => fn -> X.match(%{x: 1, y: 1}) end,
}, warmup: 1, time: 2)
"""
match 21.30 M 46.96 ns ±62508.26% 0 ns 88 ns
mapdot 20.62 M 48.51 ns ±60512.81% 3 ns 85 ns
dot 7.10 M 140.75 ns ±16462.57% 63 ns 206 ns
Comparison:
match 21.30 M
mapdot 20.62 M - 1.03x slower +1.55 ns
dot 7.10 M - 3.00x slower +93.80 ns
"""
So, compiler can optimize the code which uses . and it know that the map is map, however, compiler generates code which performs check each-time if it can’t prove that the variable map contains map (and not module).
So, there are two optimizations possible.
- Prove that the
mapis always a map. The simplest way to do this is to check if there is a module with such functions, haha - Perform check only once, and duplicate the code for each branch. This will increase the code size, but Erlang and Elixir devs usually write small functions, so I don’t except performance to decrease
2
josevalim
Creator of Elixir
I believe the issue right now is that map.x means both remote call and map lookup. So I believe it makes it impossible for the code that we generate to be optimized. We started supporting map.x and module.x() as two distinct calls and we emit some warnings when possible but it may be a while until we start emitting smarter (and smaller) code.
1
bjorng
Erlang Core Team
hst337
case x do
%{y: y} ->
case y do
%{z: z} -> {:ok, z}
_ -> :error
end
_ ->
:error
end
To
case x do
%{y: %{z: z}} -> {:ok, z}
_ -> :error
end
This particular optimization is useless, but flattening of nested cases can reduce amount of code, reduce amount of clauses and help generate more efficient switch instructions
0
josevalim
Creator of Elixir
Oh, I assume in this case this happen a lot in Elixir because of with? In this case, once maybe expressions are fully integrated to Erlang/OTP, I am hoping we can compile to something more efficient.
0
benwilson512
Author of Craft GraphQL APIs in Elixir with Absinthe
How is this knowable though? Every one of those functions you listed takes a user supplied function, and the purity of that function is not knowable.
0
bjorng
Erlang Core Team
You mean it’s useless because the Erlang compiler will generate the same BEAM code for both examples?
I would be interested in (real-world) examples where the Erlang compiler is unable to do that optimization. If we could improve the Erlang compiler to generate better code for nested cases it would benefit the entire BEAM community.
In Erlang/OTP 26, it sufficient to enable the maybe feature in the compiler. There is no longer any need to enable it in the runtime system too for it to work. We realized that we had to do that so that we could use maybe in OTP code.
5