<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>Generally, the performance should be insignificant, but…</div><div><br></div><div>ets:lookup/2: </div><div> 1 ets read (duh), but obviously, you need to write more code</div><div><br></div>application:get_env/2:<div> 1 ets read</div><div><br><div>application:get_env/1:</div><div> 2 ets reads (one to find the current application)</div><div><br></div><div>mnesia:dirty_read/1: </div><div> - 1 get()</div><div> - 3 ets reads, if data is local (where_to_read, storage_type, lookup)</div><div><br></div><div>Beyond the performance differences, there are semantic issues. Application environment variables are really meant to be static, either hard-coded in the .app file, or overridden at startup. They can also be changed at upgrades, but the expectation isn't that they change dynamically.</div><div><br></div><div>In fact, for data that is truly static, the fastest access is if the data is simply hard-coded in an erlang module. Given that modules are easy to reload, these values can still be changed with low frequency.</div><div><br></div><div>So for system preferences, it is generally better to store the values in a database. </div><div><br></div><div>In my experience, this type of data (env- and configuration data) should be cached by the application, and an event should be generated when it is updated. I wrote some support in gproc for doing this.</div><div><br></div><div><a href="https://github.com/esl/gproc/blob/master/doc/gproc.md#get_env-3">https://github.com/esl/gproc/blob/master/doc/gproc.md#get_env-3</a></div><div><br></div><div>The idea is that gproc works as both a cache and pub/sup framework, so the processes that have cached a value can easily be notified if the value changes.</div><div><br></div><div>BR,</div><div>Ulf W</div><div><br></div><div><div>On 1 Jun 2011, at 21:39, Mike Oxford wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">ETS-backed (replicated, ram-only) mnesia dirty-reads (or ets:lookup) vs application:get_env calls.<div><br></div><div>I would guess get_env > ets > dirty_reads, but does anyone have any recent performance background around these?</div>
<div>I can find some stuff from 8 years ago but nothing recent.</div><div><br></div><div>TIA!</div><div><br></div><div>-mox<br><div><br></div><div><br></div></div>
_______________________________________________<br>erlang-questions mailing list<br><a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>http://erlang.org/mailman/listinfo/erlang-questions<br></blockquote></div><br><div>
<div>Ulf Wiger, CTO, Erlang Solutions, Ltd.</div><div><a href="http://erlang-solutions.com">http://erlang-solutions.com</a></div><div><br></div><br class="Apple-interchange-newline">
</div>
<br></div></body></html>