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

[Jay Nelson]

I did an experiment recently with app.config vs https://github.com/jaynel/vbisect
vs compiled behaviour implementation of configuration. I was worried that
ets locks and row contention would penalize app.config as the number of
workers accessing the same config scaled up. I only tried it on my small
4-core laptop so far, I expect different results on a 16-core or more server.
(And all my apprehension may be misplaced as the app.config ets table
is almost always exclusively read-only.)

In theory the code-compiled constants would have the most distributed
access, followed by the binary encoded dictionary (vbisect) because a
single binary lives on the heap and is accessed from multiple places with
only a pointer pass, and lastly app.config. Turns out that the compiled
version was the slowest for one reason I completely overlooked and was
quite surprised by: Module:config_fun/N is 6x slower than a compiled
module:config_fun/N call according to the documentation.

This was enough of an impact to reduce the number of transactions to
Cassandra in half! (I was testing with https://github.com/duomark/elysium
which dynamically manages distributed sockets with stochastic decay
and 10x or more config accesses per query.)  When testing with app.config
vs binary there is a slight trend to ets slowdown with worker scale up, but
not very significant and I would want to see on a bigger machine with more
cores what the impact is.

My guess is that mochiglobal would outperform compiled code, IF you
have a constant module name. I was using a behaviour so that I could
swap configs and therefore had to use Module:fn(…) calls everywhere.
This slowdown would impact any behaviour (e.g., gen_server, gen_fsm)
you implement if it is a hotspot, as the slow function call mechanism is
fundamental to behaviour implementation.

jay