<div dir="ltr">Hi Alex,<div><br></div><div>It would be interesting to see if the cpu is busy with garbage collection when the process is reading from ETS.</div><div><br></div><div>I suspect that when the process is started without the map and then reads the map from ETS that it has to increase its heap size several times. In order to increase heap size a full GC has to be run and I have found this in the past to be quite expensive.</div><div><br></div><div>I suspect that when you create the process with <span style="font-size:12.8px">spawn(fun()-> do_something(A) end) </span> that the process is initialised with the correct heap size thereby avoiding the GC and hence the better CPU performance.</div><div><br></div><div>Perhaps you could rerun the program with a higher default heap size per process (<strong style="color:rgb(0,0,0);font-family:Verdana,Arial,Helvetica,sans-serif;font-size:medium"><span class="" style="font-family:Courier,monospace;font-weight:normal">+hms)?</span></strong></div><div><div>I would be interested to know how it goes.</div></div><div><br></div><div>Regards<br></div><div>Philip</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 15 March 2016 at 15:07, Alex Howle <span dir="ltr"><<a href="mailto:itshowlertime@gmail.com" target="_blank">itshowlertime@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">The map is not being sent as a message. It is passed in to the spawned processes by being in scope of the spawned function.</p>
<p dir="ltr">Pseudocode:</p>
<p dir="ltr">A=bigmap,<br>
spawn(fun()-> do_something(A) end).</p>
<div class="gmail_quote">On 15 Mar 2016 13:43, "Alex Howle" <<a href="mailto:itshowlertime@gmail.com" target="_blank">itshowlertime@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">The map is not being sent as a message. It is passed in to the spawned processes by being in scope of the spawned function.</p>
<p dir="ltr">Pseudocode:</p>
<p dir="ltr">A=bigmap,<br>
spawn(fun()-> do_something(A) end).</p><div><div class="h5">
<div class="gmail_quote">On 15 Mar 2016 11:32, "Sverker Eriksson" <<a href="mailto:sverker.eriksson@ericsson.com" target="_blank">sverker.eriksson@ericsson.com</a>> wrote:<br type="attribution"><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<br>
<br>
<br>
<div>On 03/15/2016 09:52 AM, Alex Howle
wrote:<br>
</div>
<blockquote type="cite">
<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>
<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>
</blockquote></div>
</div></div></blockquote></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></div>