<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><pre style="white-space: pre-wrap; widows: 1;" class=""><font face="Helvetica" class="">(Edited previous posts for relevance, including only Joe’s comments</font></pre><pre style="white-space: pre-wrap; widows: 1;" class=""><font face="Helvetica" class="">interspersed with my responses.)</font></pre><pre style="white-space: pre-wrap; widows: 1;" class=""><font face="Helvetica" class="">> 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 class="">This is exactly the approach I was taking, but I assumed that there would be</div><div class="">various implementations so I used a behaviour to identify the specific config:</div><div class=""><br class=""></div><div class=""><a href="https://github.com/duomark/elysium/blob/master/src/elysium_config.erl#L95-L108" class="">https://github.com/duomark/elysium/blob/master/src/elysium_config.erl#L95-L108</a></div><div class=""><a href="https://github.com/duomark/elysium/blob/master/src/elysium_default_config.erl#L19-L39" class="">https://github.com/duomark/elysium/blob/master/src/elysium_default_config.erl#L19-L39</a></div><div class=""><br class=""></div>The data set is quite small as it is normal app configuration data.<div class="">I implemented in the most straightforward obvious way:<div class=""><br class=""></div><div class=""><a href="https://github.com/duomark/elysium/blob/master/src/elysium_config.erl#L268-L273" class="">https://github.com/duomark/elysium/blob/master/src/elysium_config.erl#L268-L273</a></div><div class=""><br class=""></div><div class="">It turns out the Config_Module:fn(…) is the killer of performance. This alternative</div><div class="">approach is much more performant if you are ever faced with a similar situation</div><div class="">(example from some code I was browsing recently):</div><div class=""><br class=""></div><div class=""><a href="https://github.com/knutin/elli/blob/master/src/elli_tcp.erl#L51-L54" class="">https://github.com/knutin/elli/blob/master/src/elli_tcp.erl#L51-L54</a></div><div class=""><br class=""></div></div><div class=""><pre style="white-space: pre-wrap; widows: 1;" class=""><font face="Helvetica" class="">> Making a module containing all the config data
> and recompiling when necessary is certainly the fastest way</font></pre><pre style="white-space: pre-wrap; widows: 1;" class=""><font face="Helvetica" class="">> to access the data -this has very fast reads but very slow writes - you could think of a</font></pre><pre style="white-space: pre-wrap; widows: 1;" class=""><font face="Helvetica" class="">> module as a database optimized for reads but not writes :-)</font></pre><div class="">So I thought as well, but you *must* call it with a compiled module name or</div></div><div class="">eliminate the performance benefit. I mostly wanted to guarantee distributed</div><div class="">lock-free code access for many concurrent readers to avoid contention, but</div><div class="">it proved the slowest of the 3 approaches when using a behaviour.</div><div class=""><br class=""></div><div class="">jay</div><div class=""><br class=""></div></body></html>