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?
On Thu, Oct 27 2022 at 5:25 PM, Brandon Gillespie < bran...@cold.org > wrote: > > > > On 10/27/22 3:42 PM, José Valim wrote: > > > >> > 1. Maps are slower (significantly enough to avoid IMHO), but do give the >> flexibility desired (1.79x slower, which could compound if in the wrong >> place) >> >> >> Do you have a source for the 1.79 slower? >> >> >> >> I don't expect maps to be slower but, more importantly, the difference >> here should be negligible because options rarely exceed more than a dozen >> keys and in those scenarios lookups are in the order of single-digit >> microseconds ( source ( >> https://github.com/erlang/otp/issues/6139#issuecomment-1182995087 ) ) *in >> the worst case*. So it seems counter productive to say you wouldn't pick >> the more flexible option because an operation will take 1.75us instead of >> 1us (assuming it is indeed slower). :) >> >> >> Plus maps have other benefits such as reading multiple keys at once which >> will certainly offset keyword lists. >> >> > > > > 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). > > > > > What drove me to look into this is a very specific situation we face in my > project where we process a high frequency of events on a databus per > second, and it was bogging down. As I isolated easy wins (external > database calls) I started looking into other inefficiencies. > > > > Specifically this is a call that looks at the before and after state of a > struct and from that decides if changes should be handled or not. > > > > I expect many will likely find fault with the implementation of this > benchmark, but it is for a specific use case... for the room in general: > let's not digress on if there are better ways to do a thing or not :) > > > > > The gist includes three scenarios: > > > > > * ordered — arguments are given in order and pipelined (this is what we > are using now) > > * map_get — arguments are culled ala Map.take() > * map_pattern — arguments use a pattern match w/a dictionary > > > > > The #'s: > > > > Name ips average deviation median > 99th % > ordered 5.06 M 197.65 ns ±21980.53% 143 ns > 230 ns > map_get 3.86 M 259.27 ns ±28310.93% 183 ns > 494 ns > map_pattern 2.39 M 418.72 ns ±11140.31% 426 ns > 551 ns > > Comparison: > ordered 5.06 M > map_get 3.86 M - 1.31x slower +61.61 ns > map_pattern 2.39 M - 2.12x slower +221.07 ns > > > > > > > > > The gist / benchmark that created the above: > https://gist.github.com/srevenant/ed28a0cf2a167379a21eb482291313ce > > > > > > > > > > Why the change? > > > > > I did change it from when I ran it previously to come up with the 1.79x > number, because it was referencing our code base, and in the previous > benchmark I had less arguments it was matching against. I added a few more > arguments to amplify the situation, as you can see. > > > > I do realize this is NOT the heart of my performance problem, so I hope > others can avoid digressing into "you should do it this other way" type > discussions :D > > > > > This is just something that came out of exploring some performance issues. > > > > > And the suggestion for efficient named arguments came because we'd > switched to ordered arguments, and then the code was flipped in one place > (a, b) vs (b, a) (face-palm) > > > > -Brandon > > > > > > > -- > 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/f3307a40-b4fe-c66f-0576-a162202dfee2%40cold.org > ( > https://groups.google.com/d/msgid/elixir-lang-core/f3307a40-b4fe-c66f-0576-a162202dfee2%40cold.org?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 elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/l9rn6rom.0571cb07-82c4-44b5-a702-4f036f71a797%40we.are.superhuman.com.
