Thanks Marten, so I think we can proceed with a PR for Map.filter and Map.map, both passing tuples as argument. Note we will need the same for Keyword. Could you please submit it?
On Fri, Sep 10, 2021 at 11:08 PM Allen Madsen <[email protected]> wrote: > Perhaps also benchmark the combination of Enum.filter/2 and Enum.into/2, > since this is the current way with the elixir standard library. > > Allen Madsen > http://www.allenmadsen.com > > > On Fri, Sep 10, 2021 at 1:21 PM Wiebe-Marten Wijnja <[email protected]> > wrote: > >> 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. >> >> >> >> [image: 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]> >> 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) >>> >>> 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]> >>> 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]> 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]> >>>>> 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]. >>>>>> 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]. >>> 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]. >> 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 >> <https://groups.google.com/d/msgid/elixir-lang-core/e35fd630-9955-a674-c02b-d29a17b29f91%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]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/CAK-y3Cs2%2BQr_m6e_3R41H44iwcj65D4OHT9hZ2_P2FnVPhzE0Q%40mail.gmail.com > <https://groups.google.com/d/msgid/elixir-lang-core/CAK-y3Cs2%2BQr_m6e_3R41H44iwcj65D4OHT9hZ2_P2FnVPhzE0Q%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/CAGnRm4L1RaXVAcwCnDvNT9Ze%2BZoghgW7GuAOwbuR6-emeOxPBA%40mail.gmail.com.
