<div dir="ltr">This thread has me wondering exactly what optimizations, if any, BEAM tries to make on state being passed in OTP behavior callbacks.  Naively I would assume that such an optimization would be pretty cheap and high value, and so someone would have thought of that and implemented something such that the last argument to an OTP callback is not just recopied onto the stack every time but rather kept somewhere special and referenced.  Maybe I should go look at the source.<div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 17, 2015 at 10:01 AM, Gordon Guthrie <span dir="ltr"><<a href="mailto:gguthrie@basho.com" target="_blank">gguthrie@basho.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Imants<br>
<br>
> Quite simply, there is a lot of the code. It does a lot, too. The code<br>
> is of a size normally produced by a team of coders. The fact that I<br>
> work on it without help, and refactor it, and it works, may be a good<br>
> indicator.<br>
<br>
I have been in this situation - the answer is to refactor it into ‘pure’ and ‘impure’ functions and take the hit on common state up front.<br>
<br>
Every time you dip into the process dictionary that is another hard-to-reason-about code complexity  - you are making it worse, not fixing it… (although it might seem that you are fixing it)<br>
<br>
Gordon<br>
<br>
> Le 17 févr. 2015 à 17:44, Imants Cekusins <<a href="mailto:imantc@gmail.com">imantc@gmail.com</a>> a écrit :<br>
><br>
> Hi Gordon,<br>
><br>
> Most of the code I write is about logic, branching.<br>
><br>
> Despite what may appear (I am not afraid to write before I think<br>
> carefully because I do not write  to impress, I write when I feel<br>
> like, that's all), I did gain considerable experience in producing<br>
> robust working code in situations when colleagues and sometimes<br>
> managers had simply given up.<br>
><br>
> The state referred to could be inputs, an accumulated result of input<br>
> processing, parent process info, current stage.<br>
><br>
> Quite simply, there is a lot of the code. It does a lot, too. The code<br>
> is of a size normally produced by a team of coders. The fact that I<br>
> work on it without help, and refactor it, and it works, may be a good<br>
> indicator.<br>
><br>
> Frequent refactoring is caused by the code growing organically rather<br>
> than carefully planned. The main reason being: I do not think twice<br>
> before changing requirements, specs. Also, whenever I get an idea, I<br>
> refactor as much as necessary.<br>
><br>
> Basically, there is a lot of work. Common state will help me speed it up.<br>
><br>
> I'll get there ;)<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div>