<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Aug 20, 2018 at 11:31 AM Benoit Chesneau <<a href="mailto:bchesneau@gmail.com">bchesneau@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>But with the new optimisations in Erlang 20/21 sharing literals I am wondering if it wouldn't be more efficient to use a maps there?<br></div></div></blockquote><div><br></div><div>That optimization should not effect the performance of the lookups at all. It will change how much it will cost to send the values once you have done the lookup, but that should be the same with both approaches.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>So the generated erlang file would be:</div><div><br></div><div>    -define(to_lookup_map, #{ Key1 => V1;</div><div>                                               Key2 => V2;</div><div>                                               ...</div><div>                                               KeyN => VN }).</div><div><br></div><div>     lookup(Key) -> maps:get(Key, ?to_lookup_map).</div><div><br></div><div><br>A maps would also have some benefit in compressing a little the info I guess.</div><div><br></div><div>Thoughts?  Beside that maybe having that ressource in a memory mapped file would be better? I believe that beams are fully loaded in RAM, aren't they?<br></div><div><br></div></div></blockquote><div><br></div><div>The difference in between the two approaches will depend on what the keys are. If they are strings (list or binary) then I doubt that the maps code will be able to beat compiled beam code. If they are integers, then maybe maps will stand a chance, unless the compiler is able to build a jump table of the integers.</div><div><br></div><div>There are bound to be cases where the maps approach is faster, but I can't think of any right now.</div><div><br></div><div>As always, measure measure measure.</div></div></div>