<div dir="ltr">What prevents you using <div><br></div><div>generic_config:data_one(Config, ...)</div><div><br></div><div>instead of </div><div><br></div><div>Config_Module:data_one(...)</div><div><br></div><div>It is just one more step of indirection. It can be a viable way in the case when write operations are very rare.</div><div><br></div><div>Hynek<br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 11, 2015 at 8:02 PM, Jay Nelson <span dir="ltr"><<a href="mailto:jay@duomark.com" target="_blank">jay@duomark.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><pre style="white-space:pre-wrap"><font face="Helvetica">(Edited previous posts for relevance, including only Joe’s comments</font></pre><pre style="white-space:pre-wrap"><font face="Helvetica">interspersed with my responses.)</font></pre><pre style="white-space:pre-wrap"><font face="Helvetica">> If it's small you could define this in a module and not use a database
> or process at all.

> -module(global_data).
> -export(...)

> data_one() ->
>    ....

> Then dynamically change and recompile the module. Any call
> global_data:data_one() will pick up the value from the "latest version"

> /Joe
</font></pre><div>This is exactly the approach I was taking, but I assumed that there would be</div><div>various implementations so I used a behaviour to identify the specific config:</div><div><br></div><div><a href="https://github.com/duomark/elysium/blob/master/src/elysium_config.erl#L95-L108" target="_blank">https://github.com/duomark/elysium/blob/master/src/elysium_config.erl#L95-L108</a></div><div><a href="https://github.com/duomark/elysium/blob/master/src/elysium_default_config.erl#L19-L39" target="_blank">https://github.com/duomark/elysium/blob/master/src/elysium_default_config.erl#L19-L39</a></div><div><br></div>The data set is quite small as it is normal app configuration data.<div>I implemented in the most straightforward obvious way:<div><br></div><div><a href="https://github.com/duomark/elysium/blob/master/src/elysium_config.erl#L268-L273" target="_blank">https://github.com/duomark/elysium/blob/master/src/elysium_config.erl#L268-L273</a></div><div><br></div><div>It turns out the Config_Module:fn(…) is the killer of performance. This alternative</div><div>approach is much more performant if you are ever faced with a similar situation</div><div>(example from some code I was browsing recently):</div><div><br></div><div><a href="https://github.com/knutin/elli/blob/master/src/elli_tcp.erl#L51-L54" target="_blank">https://github.com/knutin/elli/blob/master/src/elli_tcp.erl#L51-L54</a></div><div><br></div></div><div><span class=""><pre style="white-space:pre-wrap"><font face="Helvetica">> Making a module containing all the config data
> and recompiling when necessary is certainly the fastest way</font></pre></span><pre style="white-space:pre-wrap"><font face="Helvetica">> to access the data -this has very fast reads but very slow writes - you could think of a</font></pre><span class=""><pre style="white-space:pre-wrap"><font face="Helvetica">> module as a database optimized for reads but not writes :-)</font></pre></span><div>So I thought as well, but you *must* call it with a compiled module name or</div></div><div>eliminate the performance benefit. I mostly wanted to guarantee distributed</div><div>lock-free code access for many concurrent readers to avoid contention, but</div><div>it proved the slowest of the 3 approaches when using a behaviour.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>jay</div><div><br></div></font></span></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" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div></div></div>