[erlang-questions] Retrieving "semi-constant" data from a function versus Mnesia

Jay Nelson <>
Mon May 11 20:02:11 CEST 2015

(Edited previous posts for relevance, including only Joe’s comments
interspersed with my responses.)
> 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
This is exactly the approach I was taking, but I assumed that there would be
various implementations so I used a behaviour to identify the specific config:

https://github.com/duomark/elysium/blob/master/src/elysium_config.erl#L95-L108 <https://github.com/duomark/elysium/blob/master/src/elysium_config.erl#L95-L108>
https://github.com/duomark/elysium/blob/master/src/elysium_default_config.erl#L19-L39 <https://github.com/duomark/elysium/blob/master/src/elysium_default_config.erl#L19-L39>

The data set is quite small as it is normal app configuration data.
I implemented in the most straightforward obvious way:

https://github.com/duomark/elysium/blob/master/src/elysium_config.erl#L268-L273 <https://github.com/duomark/elysium/blob/master/src/elysium_config.erl#L268-L273>

It turns out the Config_Module:fn(…) is the killer of performance. This alternative
approach is much more performant if you are ever faced with a similar situation
(example from some code I was browsing recently):

https://github.com/knutin/elli/blob/master/src/elli_tcp.erl#L51-L54 <https://github.com/knutin/elli/blob/master/src/elli_tcp.erl#L51-L54>

> Making a module containing all the config data
> and recompiling when necessary is certainly the fastest way
> to access the data -this has very fast reads but very slow writes - you could think of a
> module as a database optimized for reads but not writes :-)
So I thought as well, but you *must* call it with a compiled module name or
eliminate the performance benefit. I mostly wanted to guarantee distributed
lock-free code access for many concurrent readers to avoid contention, but
it proved the slowest of the 3 approaches when using a behaviour.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150511/63ab88a6/attachment.html>

More information about the erlang-questions mailing list