[erlang-questions] Process scope variable

[Felix Gallo]

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.


On Tue, Feb 17, 2015 at 10:01 AM, Gordon Guthrie <gguthrie@REDACTED> wrote:

> Imants
>
> > Quite simply, there is a lot of the code. It does a lot, too. The code
> > is of a size normally produced by a team of coders. The fact that I
> > work on it without help, and refactor it, and it works, may be a good
> > indicator.
>
> 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.
>
> 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)
>
> Gordon
>
> > Le 17 févr. 2015 à 17:44, Imants Cekusins <imantc@REDACTED> a écrit :
> >
> > Hi Gordon,
> >
> > Most of the code I write is about logic, branching.
> >
> > Despite what may appear (I am not afraid to write before I think
> > carefully because I do not write  to impress, I write when I feel
> > like, that's all), I did gain considerable experience in producing
> > robust working code in situations when colleagues and sometimes
> > managers had simply given up.
> >
> > The state referred to could be inputs, an accumulated result of input
> > processing, parent process info, current stage.
> >
> > Quite simply, there is a lot of the code. It does a lot, too. The code
> > is of a size normally produced by a team of coders. The fact that I
> > work on it without help, and refactor it, and it works, may be a good
> > indicator.
> >
> > Frequent refactoring is caused by the code growing organically rather
> > than carefully planned. The main reason being: I do not think twice
> > before changing requirements, specs. Also, whenever I get an idea, I
> > refactor as much as necessary.
> >
> > Basically, there is a lot of work. Common state will help me speed it up.
> >
> > I'll get there ;)
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150217/aaf077ab/attachment.htm>