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

[Hynek Vychodil]

What prevents you using

generic_config:data_one(Config, ...)

instead of

Config_Module:data_one(...)

It is just one more step of indirection. It can be a viable way in the case
when write operations are very rare.

Hynek

On Mon, May 11, 2015 at 8:02 PM, Jay Nelson <jay@REDACTED> wrote:

> (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_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
>
> 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
>
> > 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.
>
> jay
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150513/cb5c5f7f/attachment.htm>