[erlang-questions] Question about implementation

[Max Lapshin]

For example I have such gen_server:

-record(state,
field1,
field2,
field3,
counter = 0
}.



handle_info(incr, #state{counter = Counter} = State) ->
{noreply, State#state{counter = Counter + 1}};


Will here whole #state{} be deep-copied with new Counter +1 field, or
it is possible to guess, that here optimization is possible and just
"edit" counter field in existing tuple?

Is it possible to understand by erlang source code, that State is no
longer referenced anywhere to avod large allocation and free?
_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

[Lukas Larsson]

Hello,

Only the tuple which is the record and the immidiates (i.e. small int,
atom, pid, ref etc) will be copied. All other parts use pointers
internally and the same pointers will be copied into the correct
places within the tuple. So in this case a new 6 word memory block
will be created and filled with the atom undefined and finally the new
counter.

I think that the compiler does some optimization based on updating
tuples within the same function body, though I've forgotten what it is
it does.

Hope that makes sense.

Lukas

[Max Lapshin]

On Mon, Sep 10, 2012 at 8:08 PM, Lukas Larsson
<lu...@erlang-solutions.com> wrote:
> Hello,
>
> Only the tuple which is the record and the immidiates (i.e. small int,
> atom, pid, ref etc) will be copied. All other parts use pointers
> internally and the same pointers will be copied into the correct
> places within the tuple. So in this case a new 6 word memory block
> will be created and filled with the atom undefined and finally the new
> counter.
>

Thank you!


It is right what I wanted to hear. No deep copy, only reallocation of
top-level tuple.

[Daniel Dormont]

On Mon, Sep 10, 2012 at 12:08 PM, Lukas Larsson <lu...@erlang-solutions.com> wrote:

Hello,

Only the tuple which is the record and the immidiates (i.e. small int,
atom, pid, ref etc) will be copied. All other parts use pointers
internally and the same pointers will be copied into the correct
places within the tuple. So in this case a new 6 word memory block
will be created and filled with the atom undefined and finally the new
counter.

I think that the compiler does some optimization based on updating
tuples within the same function body, though I've forgotten what it is
it does.

This bit? http://www.erlang.org/doc/efficiency_guide/commoncaveats.html#id61731

[Max Lapshin]

>
> This bit?
> http://www.erlang.org/doc/efficiency_guide/commoncaveats.html#id61731
>


Exactly! Thanks.

[Richard O'Keefe]

On 11/09/2012, at 2:27 AM, Max Lapshin wrote:
> Will here whole #state{} be deep-copied with new Counter +1 field,

No it will be *shallow*-copied. You get a new #state term, but
any fields that are not changed will not themselves be copied.

> or
> it is possible to guess, that here optimization is possible and just
> "edit" counter field in existing tuple?
>
> Is it possible to understand by erlang source code, that State is no
> longer referenced anywhere to avod large allocation and free?

For the special case of states passed around loops of private functions
it ought to be possible to infer that a function argument is not shared
but for exported functions it is not possible because it depends on the
callers.

[Loïc Hoguin]

Hello,

On 09/10/2012 07:35 PM, Daniel Dormont wrote:
>
> On Mon, Sep 10, 2012 at 12:08 PM, Lukas Larsson
> <lu...@erlang-solutions.com <mailto:lu...@erlang-solutions.com>> wrote:
>
> Hello,
>
> Only the tuple which is the record and the immidiates (i.e. small int,
> atom, pid, ref etc) will be copied. All other parts use pointers
> internally and the same pointers will be copied into the correct
> places within the tuple. So in this case a new 6 word memory block
> will be created and filled with the atom undefined and finally the new
> counter.
>
> I think that the compiler does some optimization based on updating
> tuples within the same function body, though I've forgotten what it is
> it does.
>
>
> This bit?
> http://www.erlang.org/doc/efficiency_guide/commoncaveats.html#id61731

Is the optimization applied automatically to records?

--
Loïc Hoguin
Erlang Cowboy
Nine Nines
http://ninenines.eu

[Robert Virding]

Yes. There are a few rules which need to be followed so that the compiler can safely do this optimisation, and generally doing multiple updates to a record *in one go* will satisfy these rules. So

X1 = X0#r{a=foo(),b=bar(),c=baz()},

will be optimised, while

X1 = X0#r{a=foo()},
X2 = X1#r{b=bar()},
X3 = X2#r{c=baz()},

will not. It always tries to do this optimisation but it is generally seldom safe to do it.

Robert