<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 4, 2014 at 10:33 AM, Olivier BOUDEVILLE <span dir="ltr"><<a href="mailto:olivier.boudeville@edf.fr" target="_blank">olivier.boudeville@edf.fr</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><font face="sans-serif">Thanks in advance for any hint!</font>
</blockquote></div><br>In the case of large ETS tables which hold lots of data, the 'compressed' option is of interest in such a setup. It trades memory usage for CPU cycles. But on modern CPUs, this gap is probably smaller than what people think.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">The best solution is to decide upon a critical breaking point where you stop wasting time on optimizing for a single node and begin considering introducing multiple nodes. The switch has an overhead, but hunting for small amounts of memory seem wasteful.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">Also consider that memory bounds on modern machines tend to go up. In two years, you will probably have 64 gigabyte machines at Amazon without any hitch where we use 32 gigabyte now.<br>

<br clear="all"><div><br></div>-- <br>J.
</div></div>