<p dir="ltr">Thanks Lukas, </p>
<p dir="ltr">That is very very helpful information as it not only gives me knowledge of what to benchmark, it also gives me  some surprising insights on how to reorganise my (now obviously naive) code.</p>
<p dir="ltr">Apart from GC, is there anything else I should be concerned about like costly locks and memory barriers? For instance, is a fat mutex held for all schedulers when scanning all the process heaps?</p>
<p dir="ltr">- Edmond -</p>
</br><hr style="border:0;height:1px;color:#999;background-color:#999;width:100%;margin:0 0 9px 0;padding:0;"><span style="font-size:14px; color:#999999;">On Tuesday, 19 September 2017 at 19:40 Lukas Larsson <<span style="color:#0000A0">lukas@erlang.org</span>> wrote:</span><br></br>
<div id="AOLMsgPart_2_7856b2ce-5c1f-4267-a0d3-a3b77b6934fc">
<div class="aolReplacedBody"><div dir="ltr"><div class="aolmail_gmail_extra"><div class="aolmail_gmail_quote">On Tue, Sep 19, 2017 at 11:13 AM, Adam Lindberg <span dir="ltr"><<a href="mailto:hello@alind.io" target="_blank">hello@alind.io</a>></span> wrote:<br><blockquote class="aolmail_gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Cost wise I'm not sure, but I would advice you to benchmark for your use case.<br></blockquote><div><br></div><div>Every time you purge a module, each process heap is scanned for any sign of the old literals (aka constants) and if a literal is found a GC is done of that process which copies the literal onto its heap.</div><div><br></div><div>So the cost depends on the total heap size of all running processes and the number of processes that have a reference to those literals on their heaps at the moment of the purge.</div><div><br></div><div>Lukas</div><div><br></div></div></div></div>
</div>
</div>