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-questi...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
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.
> 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-questi...@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
> 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.
_______________________________________________
erlang-questions mailing list
erlang-questi...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
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.
> > 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-questi...@erlang.org
> > http://erlang.org/mailman/listinfo/erlang-questions > _______________________________________________
> erlang-questions mailing list
> erlang-questi...@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
> 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.
> 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.
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
----- Original Message ----- > From: "Loïc Hoguin" <es...@ninenines.eu> > To: "Daniel Dormont" <d...@greywallsoftware.com> > Cc: "Lukas Larsson" <lu...@erlang-solutions.com>, "Erlang-Questions Questions" <erlang-questi...@erlang.org> > Sent: Saturday, 15 September, 2012 1:45:58 AM > Subject: Re: [erlang-questions] Question about implementation
> 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.
