<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div>Hi Joe !<br><br></div>Thank you very much for a resolving answer/response indeed !<br><br></div>This is my debut / first ever communication/message-interchange with you by the way   :-) <br></div>( but I have been aware of <span>Erlang</span>  ....you ..and some of the other community-active users for a few years now ).<br><br></div><div>And also ... Thank you way ...way more for your contribution of/to a language being absolutely marvelously flexible & simplistic to use in real life prototyping/"testing out"-situations ( it even beats Python in this regard if you ask me ). <br></div><div><br><br></div>It struck me yesterday that I actually have two other more "generic" <span>Erlang</span>-question as well .....but which happen to fit in completely naturally & closely under this current question-<span>thread by their nature .....so I put them here too.</span>  <br><br>1:<br></div>Are fixed data, defined & compiled inside functions, always stored inside & referenced from the constant-pool of the particular modules regardless of what Erlang term-types/structures they holds ....or does it exist special situations when such fixed data becomes partly or fully copied into the heap/stack of the calling process ? <br><br>2:<br></div>In the current web-application project I work with (implemented on top of Yaws) I have the following type of function-call construct ( to achieve server-side method-dispatching )<br><br></div>Variable_module_name:fixed_function_name(),<br><br></div>According to the efficiency-guide of the Erlang-documentation this type of call-construct is more "expensive" (about six times) compare to a fully fixed name function-call. <br><br></div>In what sense is it more expensive ?  ....is it about the time-lag between the point when the VM catch/discovers this call-construct and the point when the functional content (the prepared sub-routines) actually can be executed ?<br><br><br></div>Once again ....thank you very much for contributing this language to the programmer-community.<br></div>Sending my best regards !<br><br></div>Peter , Lund Sverige     <br></div><div class="gmail_extra"><br><div class="gmail_quote">2015-05-11 14:32 GMT+02:00 Joe Armstrong <span dir="ltr"><<a href="mailto:erlang@gmail.com" target="_blank">erlang@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Sun, May 10, 2015 at 10:32 PM, Benoit Chesneau <<a href="mailto:bchesneau@gmail.com">bchesneau@gmail.com</a>> wrote:<br>
><br>
><br>
> On Sun, May 10, 2015 at 10:23 PM Joe Armstrong <<a href="mailto:erlang@gmail.com">erlang@gmail.com</a>> wrote:<br>
>><br>
>> How large is the total data?<br>
>><br>
>> If it's small you could define this in a module and not use a database<br>
>> or process at all.<br>
><br>
><br>
> How small should it be? What if the compiled bean is about 888 kilobytes?<br>
<br>
</div></div>It depends :-)<br>
<br>
There are many factors involved:<br>
<br>
   a) How much memory do you have<br>
   b) How often do you want to change the configuration data<br>
   c) How quick do you the change to be<br>
<br>
Assume<br>
<br>
  a) is a smallish number of GBytes (normal these days)<br>
  b) is "relatively rarely" (I don't know what this means - (aside - this is why<br>
      I always ask people to provide numbers in their questions))<br>
     Say once a day<br>
  c) is a few seconds<br>
<br>
Then it should be perfectly doable. Making a module containing all the<br>
config data<br>
and recompiling when necessary is certainly the fastest way to access the data -<br>
this has very fast reads but very slow writes - you could think of a<br>
module as a database<br>
optimized for reads but not writes :-)<br>
<br>
/Joe<br>
<br>
<br>
<br>
><br>
> - benoit<br>
</blockquote></div><br></div>