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

[Michael Truog]

On 05/10/2015 01:04 PM, Jay Nelson wrote:
> I did an experiment recently with app.config vs https://github.com/jaynel/vbisect
> vs compiled behaviour implementation of configuration. I was worried that
You might want to try https://github.com/knutin/bisect too.


> 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
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions