I've done some benchmarking
Implementations:
* :maps.filter(pred, map_or_iter): The baseline we benchmark against.
Expects a two-parameter function, which goes against Elixir idioms,
where a two-element tuple would be used instead.
* MapsFilterProf.wrapped_filter(map_or_iter, fun): Wraps
:maps.filter/2, to adapt it to a two-element tuple input.
* MapsFilterProf.direct_filter(map_or_iter, fun): Re-implements
:maps.filter/2 directly, with the assumption that this might be more
performant than wrapping a function with an extra intermediate
anonymous function.
* MapsFilterProf.direct_filter_inlined(map_or_iter, fun): Similar to
direct_filter/2, but inlines the other fnctions the other
implementation would call from the :maps module as well (most
importantly: next/1 which is called once per map element). This is
done since local function calls are usually faster (and more often
optimized by the compiler) than inter-module function calls.
log-log graph comparing the four filter-implementations, plotting
map-size against time.
Benchmarking was done on Elixir 1.12.0 / Erlang 24.0.1, on an x86-64
Linux machine with 8GB RAM.
It can clearly be seen from this graph that the difference in
implementations is very small.
Especially the difference between |direct_filter_inlined/2| vs.
|:maps.filter/2| is neglegible. |wrapped_filter/2| is,
as was expected, a little bit (averaging at ~20-40%) slower than the
former two.
On average, the |direct_filter_inlined/2| seems to be slightly faster
than the non-inlined version.
This difference is small, but significant (i.e. reproducible across
benchmark re-runs).
Repo with implementation + benchmarking details
<https://github.com/Qqwy/elixir-profiling-maps_filter>
The particular benchmark I wrote filters all odd values from a map that
has the shape %{0 => 0, 1 => 1, 2 => 2, ... n => n}.
This seems like an appropriate test for filtering maps, but maybe there
are even better ideas?
~Marten/Qqwy
On 09-09-2021 21:44, José Valim wrote:
> Exactly. You can build profiling on top of that and let us know how
> the different approaches go!
>
> On Thu, Sep 9, 2021 at 8:22 PM Wiebe-Marten Wijnja <[email protected]
> <mailto:[email protected]>> wrote:
>
> Sorry for double-posting, but what also might be relevant is that
> other than I thought `:maps.filter` is not a BIF (c. f. its
> implementation at
> https://github.com/erlang/otp/blob/master/lib/stdlib/src/maps.erl#L300)
> <https://github.com/erlang/otp/blob/master/lib/stdlib/src/maps.erl#L300)>
>
> We might be able to write our own alternative that wraps the
> interface one level of abstraction lower, i. e. building on top of
> the map iterators and from_list functions directly.
>
> On September 9, 2021 6:13:00 PM UTC, Wiebe-Marten Wijnja
> <[email protected] <mailto:[email protected]>> wrote:
>
> Where can the results of the benchmark/profiling be found? I
> wonder if there are tricks to reduce the overhead. Also, maybe
> the impact of this might possibly be less in newer OTP
> versions, which is something that might be worth checking.
>
> On September 9, 2021 12:31:54 PM UTC, "José Valim"
> <[email protected] <mailto:[email protected]>> wrote:
>
> Last time we had this discussion, the main concern was
> that :maps.filter emits key, value as arguments instead of
> being in a tuple, and that was incongruent to the rest of
> Elixir’s API. We could wrap it in a tuple, but that added
> some considerable overhead. So we need to make a choice.
>
> On Thu, Sep 9, 2021 at 14:09 Adam Millerchip
> <[email protected] <mailto:[email protected]>> wrote:
>
> Bump. Is there any opposition to this? I might
> (eventually) take a look if nobody beats me to it, as
> long as there isn't any opposition.
> On Friday, 12 March 2021 at 06:18:06 UTC+9 Keith
> Salisbury wrote:
>
> Was there a reason this didn't fly?
>
>
> --
> 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
> [email protected]
> <mailto:[email protected]>.
> To view this discussion on the web visit
>
> https://groups.google.com/d/msgid/elixir-lang-core/fd2477c3-0983-4cba-a1fb-7de308fee6dfn%40googlegroups.com
>
> <https://groups.google.com/d/msgid/elixir-lang-core/fd2477c3-0983-4cba-a1fb-7de308fee6dfn%40googlegroups.com?utm_medium=email&utm_source=footer>.
>
> -- Sent from my Android device with K-9 Mail. Please excuse my
> brevity.
>
> -- Sent from my Android device with K-9 Mail. Please excuse my
> brevity.
> --
> 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 [email protected]
> <mailto:[email protected]>.
> To view this discussion on the web visit
>
> https://groups.google.com/d/msgid/elixir-lang-core/E41D08E3-85FF-422B-A48A-6AC129CF3C72%40resilia.nl
>
> <https://groups.google.com/d/msgid/elixir-lang-core/E41D08E3-85FF-422B-A48A-6AC129CF3C72%40resilia.nl?utm_medium=email&utm_source=footer>.
>
> --
> 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 [email protected]
> <mailto:[email protected]>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4J0DiHv2Pmq%3DY3kvhss_RjrLZRGs3j1yRMS%3DJK7Binrzw%40mail.gmail.com
> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4J0DiHv2Pmq%3DY3kvhss_RjrLZRGs3j1yRMS%3DJK7Binrzw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/elixir-lang-core/e35fd630-9955-a674-c02b-d29a17b29f91%40resilia.nl.
OpenPGP_signature
Description: OpenPGP digital signature
