<div dir="ltr"><div>If your map is "flat" and you frequently access individual keys, then you can avoid copying by restructuring:<br><br></div>If you have {Key, Map} then store [{{Key, K}, V} || {K, V} <- maps:to_list(Map)] and look up by using {Key, K} where K is the desired map key. This can break the large map into smaller chunks which may be more amenable to copying around.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 15, 2016 at 12:32 PM, Sverker Eriksson <span dir="ltr"><<a href="mailto:sverker.eriksson@ericsson.com" target="_blank">sverker.eriksson@ericsson.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    Each successful ets:lookup call is a copy operation of the entire
    term<br>
    from ETS to the process heap.<br>
    <br>
    If you are comparing ets:lookup of big map<br>
    to sending big map in message then I would expect<br>
    ets:lookup to win, as copy_shallow (used by ets:lookup)<br>
    is optimized to be faster than copy_struct (used by send).<br>
    <br>
    <br>
    /Sverker, Erlang/OTP<div><div class="h5"><br>
    <br>
    <br>
    <div>On 03/15/2016 09:52 AM, Alex Howle
      wrote:<br>
    </div>
    </div></div><blockquote type="cite"><div><div class="h5">
      
      <p dir="ltr">I've been experiencing an issue and was wondering if
        anyone else has any experience in this area. I've stripped back
        the problem to its bare bones for the purposes of this mail.</p>
      <p dir="ltr"> </p>
      <p dir="ltr">I have an Erlang 18.1 application that uses ETS to
        store an Erlang map structure. Using erts_debug:flat_size/1 I
        can approximate the map's size to be 1MB. Upon the necessary
        activity trigger the application spawns about 25 short-lived
        processes to perform the main work of the application. This
        activity trigger is fired roughly 9 times a second under normal
        operating conditions. Each of these 25 processes performs 1 x
        ets:lookup/2 calls to read from the map.</p>
      <p dir="ltr"> </p>
      <p dir="ltr">What I've found is that the above implementation has
        a CPU profile that is quite "expensive" - each of the CPU cores
        (40 total comprised of 2 Processors with 10 hyperthreaded cores)
        frequently runs at 100%. The machine in question also has 32GB
        RAM of which about 9GB is used at peak. There is no swap usage
        whatsoever. Examination shows that copy_shallow is performing
        the most work.</p>
      <p dir="ltr"> </p>
      <p dir="ltr">After changing the implementation so that the 25
        spawned processes no longer read from the ETS table to retrieve
        the map structure and, instead the map is passed to the
        processes on spawn, the CPU usage on the server is considerably
        lower.<br>
      </p>
      <p dir="ltr"> </p>
      <p dir="ltr">Can anyone offer advice as to why I'm seeing the
        differing CPU profiles?<br>
      </p>
      <br>
      <fieldset></fieldset>
      <br>
      </div></div><pre>_______________________________________________
erlang-questions mailing list
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a>
</pre>
    </blockquote>
    <br>
  </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" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">J.</div>
</div>