<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-05-09 14:35 GMT+02:00 Peter Johansson <span dir="ltr"><<a href="mailto:flexchap@gmail.com" target="_blank">flexchap@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi to all fellow Erlang-users out there !<br><br>I'm working with a web-application prototype, powered by Erlang, at the current time ..... and is for the moment preoccupied with the choose of a suitable implementation regarding in-memory storage of shared/"top-level" configuration-data terms.<br><br>This configuration-data terms holds ejson-structures ( typically 5KB - 15KB in size ) and will be consulted by the majority of the request-related processes based on cookie-association & parameters.<br><br>Since this configuration-data relatively rarely will undergo updates but still be read by almost every request-process I consider it's in-memory storage implementation as highly significant for the process-efficiency over time & shifting payload-situations.<br><br>In the case of Mnesia the configuration-terms have to be retrieved by the means of transactions of table-records into the different process-heaps, that means in-memory copy-operations which obviously will cause some overhead in the environment during the occurrence of peak-like situations.<br><br>The other case (the function case) is to template the updated ejson-structures (as the sole "return"-structures) into dedicated function-definitions, each definition hold in it's own module, and then recompile & reload those modules programmatically via special update-functions. The up to date configuration-data can then be retrieved by common processes as simple function-calls returning fixed data.<br><br>I assume/expect these sole ejson/"return"-structures to be stored into the constant-pools of the modules when these becomes loaded in memory. In such case the call to any such function into a variable-bound should result in the creation of a memory-reference for that variable pointing to the fixed structure in the module's constant-pool. <br><br>Retrieving the configuration-data in this later manner must be significantly more efficient compare to the case of transactions from Mnesia if considering both the sizes of the data-structures & the frequency under which they will be consulted/read.<br><br>Is this assumption of mine correct/true or have I missed/overlooked something in my assessment of the situation ?<br><br><br>Sending my best regards to you erlangers reading this !¬† / Peter¬† <br></div>
</blockquote></div><br></div></div>