<div dir="ltr"><div>The semantics of maps is that of a persistent data type. ETS is ephemeral. So the fit is not good. Furthermore, maps are living int he process heap and thus, they are automatically garbage collected. ETS is manually collected in contrast. So the fit is even worse.</div>

<div><br></div><div>Maps currently has no order (based on maps:map/2 and maps:fold/3), which means they can be implemented as HAMTs (like in Clojure) once they grow large. This has very good runtime behaviour, while keeping the process semantics intact. The other option is to give maps order, but then we can't use digital searching techniques anymore and must resort to balanced search trees, e.g., AVL or RB trees and friends.</div>

<div><br></div><div>The current representation is very memory efficient however. It will probably be very good for small maps with a keyset that doesn't change.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">

On Thu, Apr 10, 2014 at 10:41 AM, Max Lapshin <span dir="ltr"><<a href="mailto:max.lapshin@gmail.com" target="_blank">max.lapshin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr">Maybe I have missed something and failed to google this info, but are there any plans to store maps in ets?<div><br></div><div><br></div></div>
<br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>J.
</div>