<div dir="ltr">I'd echo Richard's message. This is exactly what the unfortunately-named 'mochiglobal' module does. If you have a large, low-write, high-read data-structure, it's perfect. Keep in mind that compiling the module may take a lot longer than copying a large datastructure between processes, and so be REALLY REALLY sure this is what you want first.<div><br></div><div>In the early days of Riak we used mochiglobal to store the ring, because then many client processes could access it at once without going through a gen_server. However, over time we realized the churn was too high for the code server and switched to something else; I think it ended up being a gen_server handling updates but putting it in a public-read ets table.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 22, 2015 at 8:18 AM, Richard Carlsson <span dir="ltr"><<a href="mailto:carlsson.richard@gmail.com" target="_blank">carlsson.richard@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"><div>If the data is constant once the table is built, and the entries are big so you don't want to copy them out from an ets table or even avoid passing them between processes (if you want to distribute the table to a large number of processes), you could generate a module, e.g. using Merl, with a lookup function that does what the trie lookup would do. It might take some effort but the speedup could be huge.<span class="HOEnZb"><font color="#888888"><br></font></span></div></div><div class="gmail_extra"><span class="HOEnZb"><font color="#888888"><br clear="all"><div><div><br>        /Richard</div></div>
<br></font></span><div class="gmail_quote"><span class="">On Thu, Oct 22, 2015 at 1:56 PM, Jesper Louis Andersen <span dir="ltr"><<a href="mailto:jesper.louis.andersen@gmail.com" target="_blank">jesper.louis.andersen@gmail.com</a>></span> wrote:<br></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><span><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 22, 2015 at 1:19 PM, Adam Krupička <span dir="ltr"><<a href="mailto:akrupicka@mail.muni.cz" target="_blank">akrupicka@mail.muni.cz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="overflow:hidden">The gen_server approach would be more efficient; most efficient would be<br>
storing a copy of the trie in each process (but also most memory<br>
wasteful).</div></blockquote></div><br></div></span><div class="gmail_extra">Alternatively, level compress[0] the first few levels into N processes.<br><br></div><div class="gmail_extra">[0] Technically you then get a concurrent level-compressed trie.<span><font color="#888888"><br></font></span></div><span><font color="#888888"><div class="gmail_extra"><br clear="all"><br>-- <br><div>J.</div>
</div></font></span></div>
<br></div></div><span class="">_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">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></span></blockquote></div><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></div>