[erlang-questions] "speed question"

[Ulf Wiger]

Generally, the performance should be insignificant, but…

ets:lookup/2: 
  1 ets read (duh), but obviously, you need to write more code

application:get_env/2:
  1 ets read

application:get_env/1:
   2 ets reads (one to find the current application)

mnesia:dirty_read/1: 
  - 1 get()
  - 3 ets reads, if data is local (where_to_read, storage_type, lookup)

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.

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.

So for system preferences, it is generally better to store the values in a database. 

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.

https://github.com/esl/gproc/blob/master/doc/gproc.md#get_env-3

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.

BR,
Ulf W

On 1 Jun 2011, at 21:39, Mike Oxford wrote:

> ETS-backed (replicated, ram-only) mnesia dirty-reads (or ets:lookup) vs application:get_env calls.
> 
> I would guess get_env > ets > dirty_reads, but does anyone have any recent performance background around these?
> I can find some stuff from 8 years ago but nothing recent.
> 
> TIA!
> 
> -mox
> 
> 
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

Ulf Wiger, CTO, Erlang Solutions, Ltd.
http://erlang-solutions.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110602/7b18fb75/attachment.htm>