> 1.79 times, as I read it, not 1.79us. And of course benchmarks being
>> highly subjective, now that I retooled it it's at 2.12x slower (see notes
>> at the very bottom for likely reasons why).
>>
> Correct. What I did is to take a reference value of 1us and multiplied it
by 1.79, to say that at this scale those numbers likely won't matter.
> The gist includes three scenarios:
>>
> Thanks for sharing. I won't go deep into this, as requested, but I want to
point out that the conclusion "maps are slower (significantly enough to
avoid)" is still incorrect for the benchmarks above.
All of those benchmarks are using map patterns because both map.field and
Map.get are also pattern matching on maps.
map.field is equivalent to:
case map do
%{field: value} -> value
%{} -> :erlang.error(:badkey)
_ -> :erlang.error(:badmap)
end
Map.get/2 is equivalent to:
case map do
%{field: value} -> value
%{} -> nil
end
To further drive this point home, you could rewrite the map_get one as:
def map_get(engine) do
map_get_take(engine.persist, engine, @take_keys, [])
end
defp map_get_take(engine, persist, [a | rest], out) do
case {engine, persist} do
{%{^a => value}, %{^a => value}} ->
map_get_take(engine, persist, rest, [{a, value} | out])
_ ->
map_get_take(engine, persist, rest, out)
end
end
defp map_get_take(_, _, [], out), do: out
And the numbers likely won't matter or be roughly the same. The point is:
you are effectively benchmarking different algorithms and not the
difference between map_get or map_pattern.
I am only calling this out because I want to be sure no one will have "maps
are slower (significantly enough to avoid)" as a take away from this
discussion.
> What if a syntax for matching on keyword lists that allowed for items in
any position was added to Elixir? Something like (just shooting from the
hip) `[…foo: bar]` ? Then you could have your cake and eat it too, right?
Valid patterns and guards are dictated by the VM. We can't compile keyword
lists lookups to any valid pattern matching and I would be skeptical about
proposing such because we should avoid adding linear lookups to patterns.
It is worth taking a step back. It is not only about asking "can we have
this feature?". But also asking (at least) if the feature plays well with
the other constructs in the language and if we can efficiently implement it
(and I believe the answer is no to both).
--
You received this message because you are subscribed to the Google Groups
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4L37yu8KVbhuM0gNkVYOzCeoXaKzTBk4aY4OLLRdgRRLg%40mail.gmail.com.
