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

Jay Nelson jay@REDACTED
Wed May 13 17:27:45 CEST 2015

> On May 13, 2015, at 12:07 AM, Hynek Vychodil <vychodil.hynek@REDACTED> wrote:
> 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

I was writing an OSS library to be reused by others. I employed
erlang’s behaviour mechanism as the “most principled” approach
to genericity. Using erlang.mk or rebar expects the library to be
fetched and used without modification during the build process.
To make it performant with this approach, I have to have documentation
that instructs the user to mirror the example default, and use a
reserved constant pre-defined module name (hoping there is no conflict
with another module already defined in their application).

I will probably benchmark this one day, but using vbisect is a more
reasonable approach and so far the traditional app.config has not
proven to be a big penalty (maybe 10% slowdown, maybe nothing
significant, I don’t have definitive production numbers).


Another reply had mentioned knutin/bisect… Bisect requires
fixed length key/value, so while it may be faster (I would expect
it’s possible but I don’t know) it has a larger memory usage and
when including things like URLs as values, that memory waste
could be vast for other values like integers. Vbisect is Kresten
Krab’s inspiration from bisect re-implemented with variable-sized
keys and values. He wanted a generic technique to store data in
Hanoi DB which is his erlang implementation of Level DB, a log
merge KV store. Performance testing and PropEr tests give results
that are similar to ets with 10K or so keys in a single dictionary,
although it will slow down with more data as it is a sorted tree of KV.
My fork adds more structure to the code, PropEr testing and some
additional API calls to mirror dict and friends of erlang, so it can be
used as a swap out alternative.


More information about the erlang-questions mailing list